Something for Delphi to be proud of… in Lion ?!

Some people often complain loudly and passionately that Delphi needs a garbage collector and that reference counting is not good enough, but if I read this correctly, in the new OS X release – ‘Lion’ – Apple seem to think that reference counting is an improvement over more sophisticated garbage collection techniques.

From the details discussed in page 10 of a a very, VERY detailed review of Lion, it seems on the face of it that Apple’s brand new “ARC” (Automatic Reference Counting) seems to work exactly like Delphi’s own automatic reference counting of interfaces (and strings and dynamic arrays…) !!  Even if not entirely identical, the similarities are certainly close enough to be worthy of a raised eyebrow or two, and a little puff of pride at Embarcadero (or among former Borland’ers, where-ever they may now be).

Where Delphi leads, it appears Apple sometimes follows…

Of this, this perhaps should not be all that surprising … some people may not be aware that Delphi owes a debt of gratitude to Apple for ObjectPascal in the first place.

Tags:

7 comments

  1. Stefan’s avatar

    You missed the point. The problem in Delphi is, that if you mix object and interface references you get the pain in the ass because the possible refcounting (yeah you cannot even be sure if the object behind the interface is actually refcounted, it could also be a TComponent, a TInterfacedPersistent or some own implementation that does not automatically free the object when the refcounter reaches zero) messes everything around.

    Interfaces how they are implemented currently are crap to use in a way they are used in other languages.

    1. Jolyon Smith’s avatar

      No, with respect I think *you* missed the point. :)

      The solution to interface counting creating problems with mixing interfaces and objects isn’t to throw out reference counting entirely (.NET style), but rather to find a way to make reference counting *work*. The point of my referencing this aspect of Lion being that whilst Apples ARC is clearly far more sophisticated than Delphi’s ARC (some 15 years old BTW, and only ever designed originally to deal with COM), the latest innovation and advance in garbage collection technology is… at it’s guts… AUTOMATIC reference counting.

      Reference counting itself is of course an aspect of COM, not Delphi. It is the fact that Delphi implemented AUTOMATIC reference counting that couples it with the changes in Lion – codifying in the compiler itself, the conventions and practices for reliable and safe reference counting, removing the burden of that from the developer.

      Apple provides greater control, but I guess that’s what you get for 15 years of progress – improvement. :)

    2. Olaf Monien’s avatar

      even though ARC may look similar to what we have in Delphi for Interfaces and Strings, it appears to work quite differently. The only common thing is that it is based on reference counting.

      The difference is that ARC appears to work by convention. This convention is one of the most important things you have to learn when you start programming for iOS/OSX. (i.e. the subtle difference between something like d1 = [NSDate date] and d2 = [[NSDate alloc] init])
      The same conventions appear to apply for manual reference counting (aka retain/release calls) *and* for ARC. This basically means if you screw up those conventions, ARC may fail.

      In Delphi there is no such convention based thing, it’s all about detecting variables getting assigned and going out of scope again – which is a completely different approach …

      1. Jolyon Smith’s avatar

        @Olaf – the way I read it, ARC is based on conventions in *both* Apple and Delphi, with those conventions being hard-wired into the compiler.

        The difference is that in Delphi you cannot turn off those conventions and with the more sophisticated Apple system you can (as well as other more sophisticated “features”)

        @Stefan – no you are still missing the point which was simply that people have dismissed “reference counting” as inefficient or just plain “old fashioned”, and here we have a current/future generation garbage collection scheme that doesn’t *replace* reference counting but which has chosen to incorporate it, and enthusiastically and comprehensively so.

        I wasn’t trying to say “See – reference counting is all you need”, just that “See – reference counting *IS* useful and legitimate”.

        I would also draw your attention to Page 11 which explains a lot of the reasons why GC is a *bad* thing for many applications and why/how Ref Counting is a useful compromise, providing an element of GC without sacrificing performance or determinism (the two big penalties with more “sophisticated” GC systems).

      2. Stefan’s avatar

        I meant the reason why people are asking for a GC in Delphi. Yes, refcounting is nice, but then you have to do it everywhere. If you are using DI for example you have to either use interfaces for everything or you have 2 different behaviours. And even if you use only interfaces if you query an interface from some non self destroying object you have to take care of this object (either its a TComponent with an owner or something else).

      3. zeroc8’s avatar

        The big question is – what have the Delphi guys done all those 15 years, besides basing their IDE on .NET and messing up the help system?

      4. Stefan’s avatar

        “I wasn’t trying to say “See – reference counting is all you need”, just that “See – reference counting *IS* useful and legitimate”.”
        On that I agree.

        Anyway as long as not everything can be refcounted this cannot be realized in Delphi. That making relying on refcounting in Delphi makes it dangerous. And this is why I personally would see a garbage collector in Delphi useful sometimes although I don’t actuallly want it.

Comments are now closed.