[fpc-pascal] Corba Interfaces and IInterface query

[Sven Barth]

On 14.11.2010 17:30, Graeme Geldenhuys wrote:
> On 14 November 2010 17:25, Sven Barth wrote:
>> 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?
>
> 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).
>

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.

> 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.
>

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.

>
>
>> 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.
>

See above.

>
>> 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.
>
>

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