[fpc-devel] Delphi anonymous methods
Marco van de Voort
marcov at stack.nl
Mon Mar 4 11:29:06 CET 2013
In our previous episode, Graeme Geldenhuys said:
> > In Delphi, synchronization primitives like queue() and synchronize() have
> > been adapted to work with them, so they are actually more used than some
> > other new features.
>
> Sure, just like Delphi implemented Advanced Records, when the Object
> type already does the exact same thing! Was "advanced records" really
> needed, NO.
Of course it was. Objects are not a binary dumpable type due to their
possible VMT link.
Moreover, from Delphi's case Objects are redundant (keep in mind they
haven't supported even the object based libraries like "Objects" since D2 or
so. It might even be D1, but I don't know that one that well)
So it makes sense to develop a clean new type, as a start to the deprecation
of TP objects (that have lingered as legacy for 17 years).
If I were Embarcadero, I'd do exactly the same.
Keep in mind that our situation is different from Delphi there. We _DO_
support objects because of TV.
> Just because Embarcadero starting using there duplicated
> functionality, doesn't make it good, or better than what existed before.
I never liked the dual nature of TObject.
> Here is an example
>
> Does the following make sense?
>
> http://docwiki.embarcadero.com/Libraries/XE3//en/System.IOUtils.TDirectory
>
> TDirectory = record
> ...
> class procedure Blablabla(...)
> end;
That's a totally different discussion. And yes, that is what modern users
ask. One can discuss if that is sane, but if you would just open your eyes,
and read the maillists (ours too) that are full of comparisons with newer OO
centric languages (Python,Java,.NET, then you understand why Embardero does
this.
Moreover, IMHO compatibility is not pick what you like. Either you are
compatible or not. And I never made a religion out of D7. IMHO D7 is as
dirty as the rest in many ways.
So it is either start with a new language/dialect from a pure principle, and
apply it everywhere, or be compatible. Mixing it only leads to infinite
discussion, slippery slopes etc.
I chose the latter. Compatibility. All the way. No compromise.
Is it pure? No. Is it perfect? No. Is it better than the alternative? Yes.
Currently FPC is much dirtier than Delphi if only because it has two
implementations for everything.
More information about the fpc-devel
mailing list