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