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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
