For example if there are two Interface : IinterfaceA,IinterfaceB can I implement these two interface in one class?

Thanks
pingyu

yu ping wrote

For example if there are two Interface : IinterfaceA,IinterfaceB can I implement these two interface in one class?

Yes, you can. Take the following example:

type
   IInterfaceA = interface
     procedure A;
   end;
   IInterfaceB = interface
     procedure B;
   end;
   TMyInterfacedObject = class(TInterfacedObject, IInterfaceA, IInterfaceB)
   public
     procedure A;
     procedure B;
   end;

Regards,
Sven

yu ping wrote

 For example if there are two Interface : IinterfaceA,IinterfaceB  can I implement these two interface in one class?

Yes you can, but be warned, Interfaces doesn't seem to be a high priority feature in FPC - I don't think many here use Interfaces. There are still some very strange things or missing features in FPC's implementation. Even though Interfaces are an extremely handy language feature in Delphi and often used, just be careful under FPC.

Hi Everybody,

Jonas Maebe wrote

Please don't spread FUD. There are several projects that make heavy use of interfaces that work fine with FPC (e.g. Zeoslib). Yes, interface delegation is not finished (other than that, interfaces work fine afaik)

Let me just clarify. I did not have a "dig" at anybody or the FPC team. I simply wanted to make the original poster aware of the limitation of FPC's Interfaces implementation to date. And no Jonas, there are still plenty of things missing from FPC's implementation, and thus it proves that hardly anybody in the FPC core team uses Interfaces now or in the past.

Two major issues (but not the only items I can list):
* incomplete delegation (non existent in FPC 2.4.2)
* No name resolution (function aliases) of conflicting interfaces

Unfortunately these are rather critical features in normal to advanced interface usage in software. If you haven't used them yet, then you have only scratched the surface of what Interfaces are useful for. So at this point, only the most basic usage (aka reference counting - memory management) of Interfaces work in FPC.

after the "interface scoping" thread on fpc-devel). If things continue like this, I will start holding all of your mails for moderation and only allow them through on a case-by-case basis, because the current situation is not tenable.

And we here start again. By all means, if it will make you feel better/happier, then why not simply unsubscribe or band my from all FPC and Lazarus related mailing lists while you Gods sakes, I was simply trying to help somebody by mentioning potential problems when using FPC's Interfaces in "real world applications". If you come from Delphi or Kylix to Free Pascal, you as a developer should be made aware of these things. In fact, there should actually be a wiki page dedicated to what FPC cannot do compared to Delphi or Kylix. This would seriously help developers wanting to move to Free Pascal, to evaluate FPC better before they make a decision. I see no harm in letting developers know what FPC cannot do yet, this might even help new contributors with ideas of what they can implement so FPC can move forward.

Graeme Geldenhuys wrote

* incomplete delegation (non existent in FPC 2.4.2)

I haven't used this for quite a long time, so I can't test it just now... what are you missing?

* No name resolution (function aliases) of conflicting interfaces

Ehhh... the following code compiles with 2.4.2 and even 2.4.0:

==== source begin ====

program interfacetest;
{$mode objfpc}
uses
   SysUtils;
type
   IMyInterface = interface
     procedure Foo;
   end;
   TMyInterfacedObject = class(TInterfacedObject, IMyInterface)
   public
     procedure IMyInterface.Foo = Bar;
     procedure Bar;
     procedure Foo;
   end;
procedure TMyInterfacedObject.Bar;
begin
   Writeln('Bar');
end;
procedure TMyInterfacedObject.Foo;
begin
   Writeln('Foo');
end;
var
   t: TMyInterfacedObject;
   i: IMyInterface;
begin
   t := TMyInterfacedObject.Create;
   try
     i := t;
     t.Foo;
     i.Foo;
   finally
     t.Free;
   end;
end.

==== source end ====

Output is:

==== output begin ====

Foo
Bar
An unhandled exception occurred at $08056B71 :
EInvalidPointer : Invalid pointer operation
$08056B71

==== output end ====

(I don't know currently where exactly that EInvalidPointer comes from.... even a "t.AddRef" doesn't solve this...)

Regards,
Sven

> * No name resolution (function aliases) of conflicting interfaces Ehhh... the following code compiles with 2.4.2 and even 2.4.0:

Typical FUD tactics: mix something people know being true with something wrong and they believe you the wrong statement.

Releasing TInterfacedObject descendants by Free is a bad idea ;) It destroys the instance without checking if there are still queried interfaces.

You're right of course...

The following code flow works:

begin
   t := TMyInterfacedObject.Create;
   i := t;
   t.Foo;
   i.Foo;
end;

But why doesn't the following?

begin
   t := TMyInteracedObject.Create;
   try
     t._AddRef;
     i := t;
     t.Foo;
     i.Foo;
     i := Nil; // shouldn't this solve the problem as well? or is this a
problem of temp inteface variables?
   finally
     t.Free;
   end;
end;

Regards,
Sven

Sven Barth wrote

>    * No name resolution (function aliases) of conflicting interfaces Ehhh... the following code compiles with 2.4.2 and even 2.4.0:

My apologies then, I must not have seen the announcement. I also looked in my ref.pdf (which was incidentally in a folder 'FPC_DOCS/new/' ) which listed in section 7.3 that it is currently not implemented. After you email, I looked at the title page of that PDF document, I noticed I have a rather old PDF, so the 'new' directory fooled me a bit, and indeed it was not a v2.4.0 version as I thought. I guess it's time I clean out my development directories a bit.

I suspect the reason is that the object still has a refCount of 1 when you free it and this code raises the exception:

    procedure TInterfacedObject.BeforeDestruction;
     begin
         if frefcount0 then
           HandleError(204);
      end;

You should never free an interfaced object directly.

Regards Andrew.

Graeme Geldenhuys wrote

By all means, if it will make you feel better/happier, then why not simply unsubscribe or band my from all FPC and Lazarus related mailing lists while you has nothing to do with with how I feel, although I can't say that I appreciate off-list moderation messages being quoted partially back to the list. I don't hold a grudge against you and there are obviously several areas where you do make useful contributions to the lists (e.g., helping people with fpgui). There is however a problem if more and more threads that you participate in end up as flame wars, draining energy from everyone involved, and even from other people too.

For now, messages from you to fpc-pascal and fpc-devel will require moderator approval.

Jonas
FPC mailing lists admin

Below is the complete message I originally sent to Graeme in private.

Graeme,

Please don't spread FUD. There are several projects that make heavy use of interfaces that work fine with FPC (e.g. Zeoslib). Yes, interface delegation is not finished (other than that, interfaces work fine afaik) and you are extremely unhappy with the way FPC is developed in general (and probably with several core developers in particular), but sending messages like the one below does not help anyone.

It's getting to the point where several people are getting really beat down and demotivated by your constant enmity (apart from comments on the mailing lists, I've also received a number of private mails about this, especially after the "interface scoping" thread on fpc-devel). If things continue like this, I will start holding all of your mails for moderation and only allow them through on a case-by-case basis, because the current situation is not tenable.

And to clarify: the problem is not criticising as such. Other people, such as Martin Schreiber, also regularly criticise FPC and I'm not aware of anyone having any problems with him. It's how you do that.

Jonas
FPC mailing lists moderator

FWIW, both interface delegation ("implements") and "method aliasing" have been supported in FPC for at least 2 years (we first tested/used them in January 2009 with FPC 2.2.2 which was released in August 2008).

* We have used method aliasing extensively - it appears to behave the same as Borland Delphi and has no issues that we have found.

* FPC's "implements" is limited compared with Borland Delphi (the "implements" property cannot use method accessors and the field must reference an interface not a class). Allowing for these limitations, we have not had problems using this feature (although have not used it "creatively").

Regards Andrew.

Graeme Geldenhuys wrote

Two major issues (but not the only items I can list): * incomplete delegation (non existent in FPC 2.4.2) * No name resolution (function aliases) of conflicting interfaces