[fpc-devel] Suggestion: reference counted objects

[Boian Mitov]

  Hi Chriss,

Personally I favor reference counted objects. While there are interfaces as you pointed, and in Delphi you can even use smart pointers now, there is still a lot of cases when you need to use objects, and have to manually free them.
In single threaded environment that is not such an issue, but in parallel and heavily multithreaded environments, reference counting is a life saver.
Just for that at the moment we have to declare gazillions of additional interfaces which slows the development considerably. After all even after we switched to the new RTTI, generics, and attributes, we barely succeeded to reduce our code from 4 mln lines of code to ~800K and it still is time consuming to maintain :-( .
Anything that can reduce the code base further and speed up our development is important for us, as I would guess for anyone else.

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------

From: Chriss Kalogeropoulos 
Sent: Saturday, September 20, 2014 4:02 AM
To: FPC developers' list 
Subject: Re: [fpc-devel] Suggestion: reference counted objects

Hi all,

Why would anyone want something like that? Both languages have interfaces that can be used for auto reference counting and they also provide us with a very powerful abstraction mechanism.
This also adds overhead on the performance (and locking calls) which might be important in some cases like embedded devices.

The fact that embarcadero added this feature unconditionally is a huge mistake IMHO unless they needed it for some compatibility reasons with java for android or iOS or just marketing, I don't know. If someone knows any other reason please post it on the list.

It's the same bad decision they made with the zero based strings, at least the used a switch for that.

The only gain I can see from that is that with objects someone can use reference counting and still benefit from some aggressive optimisation like inlining which is not possible for interfaces. The same with simple properties that they need getter and setter methods in interfaces that cannot be optimized but in objects it might be possible or they can access the data member directly.

In my opinion this is a very small gain compared to the huge change in the language semantics that you propose.

Chriss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140920/a1a0cc49/attachment.html>