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

John Briggs johneb47 at optusnet.com.au
Tue Sep 23 02:24:37 CEST 2014


On Mon, Sep 22, 2014 at 07:21:46PM +0200, Sven Barth wrote:
> Am 22.09.2014 17:11 schrieb "Jonas Maebe" <jonas.maebe at elis.ugent.be>:
> >
> >
> > On 22 Sep 2014, at 16:44, Peter Popov wrote:
> >
> >> Another comment: If referenced objects all derive from a single base,
> then, the user cannot possibly have another hierarchy, which uses ref.
> objects. As I mentioned earlier, I do this explicitly for an object well
> down my hierarchy. So, it seems to me you still need something like:
> >>
> >> -- code --
> >>
> >>
> >> TRefObject = referenced class(TWhateverBase)
> >> end;
> >
> >
> > 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.
> 
> As written in my RFC I would go the "allow it" route and provide mechanisms
> to manually access the reference count from a non-reference counted
> variable (thus being implemented in TObject). Optionally one could add a
> warning that is off by default that one could use for such cases. This
> approach is necessary, because we'd otherwise need to introduce overloads
> for e.g. RTTI functionality in TypInfo or to introduce some compiler magic
> for them (I don't like either of these two possibilities).

Sven
At the risk of starting a flame war I have been pondering this question
since these threads have started:

Why has there been so many messages on this list debating the pros and cons
of reference counting objects? 
The beauty of the Pascal language is in its structure ie:
procedures,functions,OOP. Why does it need to be a functional programming
language as well when there are Haskell, Lisp, Scheme and other functional
languages that have already done the hard work.


John



More information about the fpc-devel mailing list