[fpc-devel] weak referencing (was Suggestion:.....)

Peter Popov ppopov at hotmail.com
Mon Sep 22 17:32:52 CEST 2014



From: jonas.maebe at elis.ugent.be
To: fpc-devel at lists.freepascal.org
Date: Mon, 22 Sep 2014 17:11:08 +0200
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.....)


I would strongly recommend against that. Referenced and unreferenced objects are completely different beasts with different behaviours. If you allow that, you get all kinds of problems down the line. E.g. you either have to forbid assigning a TRefObject to a TWhateverBase (which runs counter to a very basic OOP principle), or allow it and then have the programmer deal with the resulting reference counting mess-ups.
Just like Objective-C and C++ classes cannot derive from each other, and just like Delphi-style classes and TP-style objects and objcclass and cppclass cannot derive from each other, so should reference counted and non-reference counted classes not be able to derive from each other. If you want to mix reference counted and non-reference counting functionality, use the existing interface-based pattern instead, or possibly some kind of delegation pattern.------
Indeed, this is a valid point. By the same logic, TRefObject should be a base object, should not inherit from TObject and its instance references should not be assignable to pointers. I tried to make the last point earlier. 
If you ask me, implicit ref. counting will not eliminate the mess of managing what one has created by his own will. If you create it, you are its Creator, so you must destroy it :-) But ... as long as TObject stays intact, I am ok with whatever happens. 
I will add another comment to the race condition issues: they are easily avoided by a single line assembly atomic inc/dec. It however will not resolve performance issues where a certain function assigns classes references left and right and there are multiple threads. The fact that you can easily protect it does not mean that you will retain parallel efficiency. Thread-syncing should be left to the programmer to optimize.
Peter 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140922/570c148d/attachment.html>


More information about the fpc-devel mailing list