Hi,

Below is an example of two interfaces I declared. Trying to implement them on a TObject subclass, I got a compiler error that IUnkown was not implemented in my subclass. In all units I defined {$interfaces corba}

Eventually I found out that I had to remove the (IInterface) heritage from my interface definitions. Why is IInterface bound to IIUnknown (aka COM interfaces)? In Delphi 7+ and Kylix, IInterface was not a COM interface, so I would have expected that to be usable in CORBA interfaces in FPC too, but apparently not. So what's the point of having IInterface then if it is always bound to COM? In that case, simply defined your interfaces from IUnkown as per the COM spec.

------------------------------------------------------------------
unit layout_interface;
{$mode objfpc}{$h+}
{$interfaces corba}
interface
uses
  Classes, fpg_base;
type
  ILayoutManager = interface; // forward declaration
  ILayoutManaged = interface(IInterface)
  ['{05680C87-FD6A-4E41-84CE-ADD66DB60F8E}']
    function  GetLayoutManager: ILayoutManager;
  	procedure SetLayout(ALayout: ILayoutManager);
  	property  Layout: ILayoutManager read GetLayoutManager;
  end;
  ILayoutManager = interface(IInterface)
  ['{91FF6CE0-3B18-470A-BBCF-476064891EE4}']
    procedure AddWidget(AWidget: TfpgWindowBase);
    procedure AddLayout(ALayout: ILayoutManager);
  end;
implementation
end.
------------------------------------------------------------------

It's Delphi compatible:
http://docwiki.embarcadero.com/VCL/XE/en/System.IInterface

So yes, it seems to be a COM interface even in Delphi 7+ (I don't know about Kylix though).

Regards,
Sven

I don't know that the latest Embarcadero docs say, but IInterface was introduced when Kylix was created. Kylix runs under Linux where COM doesn't exist. So IInterface was not COM driven, and as far as I know, it was made the same under Delphi to, so Kylix and Delphi are consistent in that regard.

According to this mail from 2007

IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC (although they are aliased the other way round, but that doesn't matter).

So I still say it's Delphi compatible ^^

Regards,
Sven

Sven Barth wrote

IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC (although they are aliased the other way round, but that doesn't matter).

So then comes the big question — why have IInterface then, if it is exactly the same as IUnknown, yet not a known COM interface name?

So I still say it's Delphi compatible

Is it just me or is this phrase getting a bit monotonous.

Ask Borland why they decided to do it that way... perhaps they wanted a common ancestor for they case they ever decide to use non COM interfaces... (I can only guess here)

The point is that this is the reason for many things in Free Pascal. It doesn't matter whether you like that reason or not. You and I either have to live with that or do something against it (you might argue that not everything is accepted, but that is not the topic here). Exceptions are mostly Generics, operator overloading and more generic enumerators (and the stricter syntax in *fpc modes). Oh, and let's not forget the existence of non-COM interfaces and the new constref parameter modifier. :)

Regards,
Sven

Sven Barth wrote

Ask Borland why they decided to do it that way... perhaps they wanted a common ancestor for they case they ever decide to use non COM interfaces... (I can only guess here)

This is exactly what I am saying IInterface is a non-COM interface in Kylix (so that would seem logical why they introduced IInterface, and not keep using IUnkown because the latter would make no sense under Linux), and will mostly like be the case again when Embarcadero brings out their x-platform Delphi. So with FPC already supporting COM and non-COM interfaces, it would seem logical that when CORBA interfaces are used, IInterface acts the same as Kylix, by being a non-COM interface.

I also hate open ended type definitions.
eg:
TMyClass = class

  end;

That defaults to a TObject descendant. Then in Delphi a interface definition of

  IMyInterface = interface
  end;

will actually descend from IInterface/IUnknown.

But that same interface definition descends from what, when CORBA style interfaces are used in FPC? Just nothing? This doesn't seem logical, hence I think it should also descend from IInterface like Kylix, but then be non-COM.

In our previous episode, Graeme Geldenhuys said:

This is exactly what I am saying IInterface is a non-COM interface in Kylix

Please leave IInterface alone. It took me a week of work to let the current IInterface=IUnknown alias propagate properly in fpdoc's internal structures :-)

@Graeme: I'd say this is a much better reason than "Delphi compatibility" for not touching the definition of IInterface, don't you think? :D

Besides think about the following:

Let's say IInterface would be changed to be the base ancestor type for Corba interfaces. What about existing classes that implement IInterface (which currently declares QueryInterface, AddRef and Release, cause IInterface=IUnknown)? Do they suddenly become "Corba implementing" classes? What about code that relies on the fact that reference counting works (although not in the same way as in the recent discussion about that...)?

It would be a too big change. Like the resolution for "internal error 200111022" (
http://www.hu.freepascal.org/lists/fpc-devel/2010-October/022478.html and http://bugs.freepascal.org/view.php?id=17675 ) was "allow in all modes" although it would have been nice to disallow that in mode objfpc. It would have broken just to much code. "The damage is done", so to say.

If anything than there could be a "ICorbaInterface" addad as a base ancestor for Corba interfaces. But please note that there is another inheritance supporting type that does not have a specific base class: OBJECT.

Regards,
Sven

Marco van de Voort wrote

Please leave IInterface alone. It took me a week of work to let the current IInterface=IUnknown alias propagate properly in fpdoc's internal structures :-)

:-) I can't say I saw that one coming.

No, that is controlled by -SI compiler parameter or the {$interfaces ...} directive. By default FPC defaults to COM interfaces on all platforms, even though Windows is the _only_ OS that has COM. Considering the amount of platforms FPC supports, FPC is already very accommodating to Windows users in this regard (and quite biased).

What would be a lot more logical is if FPC defaults to COM based interfaces under Windows only, which means by default there, IInterface is a IUnknown descendant and thus COM based.

Under all other OSes, (which don't have COM), FPC should default to CORBA style interfaces, where IInterface is non-COM - same as what was done in Kylix. What's the point of have COM style interface on non-Windows platforms anyway. Reference count can still be implemented in CORBA interfaces if required by the developer. Simply use TInterfacedObject for that.

What about code that relies on the fact that reference counting works (although not in the same way as in the recent discussion about that...)?

It will be business as usual, nothing will change. TInterfacedObject can still be reference counted on all platforms - CORBA style or not.

http://bugs.freepascal.org/view.php?id=17675 ) was "allow in all modes" although it would have been nice to disallow that in mode objfpc. It would

...and such decisions is the start of a downward trend for FPC. Such code should not be allowed period. FPC's designs should stay logical and clean, and it's up to the developers to maintain their application code and fixe such bad/broken code. After all, the one is a property and the other a function - very different constructs.

Either way, I don't see how this relates to Interfaces.

FPC's designs should stay logical and clean, and it's up to the developers to maintain their application code and fixe such bad/broken code.

... and as soon as we do such a logical decision, you start whining, whining about the bad fpc developers destroying your business plans. See the recent thread on fpc-devel about immediate release of unused temporary interfaces and not keeping them for an unlogical long time. Or did you forget about it already? I fear you did again ...

You didn't follow the recent discussions about XPCOM which let to the introduction of the constref modifier? XPCOM is - as the name suggests - cross platform COM and now supported by Free Pascal as well.

There is a difference: If I use CORBA interfaces the compiler WON'T increase/decrease the reference count automatically. That is THE difference between CORBA and COM interfaces.

See above.

It's not related to interfaces, but related to the fact that something like your suggestion falls into the category "breaks to much code". Those solutions will face troubles if presented to the core devs just like the more clean solution for the "duplicate identifier" problem was not implemented...

Regards,
Sven

Florian Klaempfl wrote

... and as soon as we do such a logical decision, you start whining, whining about the bad fpc developers destroying your business plans.

Bo hoo... It's called being able to maintain code in the long run. Keep adding one hack after the next might solve your problem now, but in a few years you have a unmaintainable piece of software. Windows API is prove of that. Qt and Linux API on the other hand are good examples of keeping API clean even if that means breaking code between major releases.

Or did you forget your constant nagging about needing to keep FPC maintainable in the long run... I guess you forgot.

Oh, I forgot, depending on implementation details keeps your code maintainable ...

Delphi 5 supported both "COM" and CORBA. No IInterface, only IUnknown.

Delphi 3 supported COM without I was still doing Delphi, it was 5. We used to use Interfaces all the time, but we simply reimplemented the TInterfacedObject and ignored the COM methods. We used them much as one would with in .Net these days. More about light public interfaces, encapsulation and delegation rather than ref counting and such.

M

Reference counted interfaces need compiler magic AFAIK.

Martin

Martin Schreiber wrote

> Reference counted interfaces need compiler magic AFAIK.

Indeed, you are correct.

Matt Emson wrote

methods. We used them much as one would with in .Net these days. More about light public interfaces, encapsulation and delegation rather than ref counting and such.

This is how I use interfaces too. I never to COM programming as such, but do you the various features that come with interfaces - as you mentioned. It's great for help out with circular unit reference issues too.