[fpc-devel] Modernising Pascal

[Marco van de Voort]

> Marco van de Voort wrote:
> 
> > 
> >>The best solution I can 
> >>think for this is to reference count non-component classes. This should 
> >>be safe for TObjects but obviously not for Tcomponent descendants (cf 
> >>circular reference problem) so a protected variable could be added to 
> >>TObject to specify whether to ref count it or not (with TComponent 
> >>turning it off).
> > 
> > 
> > This is impossible. 90% of the language wouldn't work anymore as it does
> > now, and besides, it would be dog slow. Could be that it gets slower than
> > Boehm GC even.
> 
> Thats very pessimistic!

No, that is reading literature.
 
> Why wouldn't existing code work with this? 
> If you call free on an object 
> it would ignore the ref count and free it

That messes up the ref counts. Make some sample code that throws some objects
to different procs and keep track of ref counts.

> Is'nt the overhead for reference counting negligible compared to having 
> try..finally blocks which the programmer would have to add anyway if we 
> didn't refcount them?

> (there also pointers for cases where you dont need try..finally)

Which one?
 
> > How do you free objects then? Those try..finally's are there actually because
> > of the refcounting.
> > 
> 
> The system frees them automatically - there no need to manually add 
> try..finally statements. The benefit is clearer code and less chance of 
> a memory leak.

Which system? The ref counting system pretty much _is_ the try finally :)

> >>2. For Each. Its in Delphi 2005 and every modern language implements it.
> > 
> > 
> > Yeah, and I still wonder why. There is nothing to gain with it. 
> 
> one less variable to manually declare

Implement something in lazarus that auto-adds the variable to the local var
section. No need for language extensions.

D2005 reasons for it lie in the .NET, but those don't apply to the non .NET world.
(yes it works in d2005/win32 too, but it is useless there)

> > I partially agree with you that the container types of Delphi aren't the
> > strongest point. However the solution is to make a lib with better types.
> > 
> > Pulling it in the compiler with ref counting however is something totally
> > else, and will make them dog slow.
> > 
> > Keep in mind that I can walk through 5-6 million (real world) objects in
> > just under 2 secs in Pascal/Delphi on an already old 2GHz P IV, and inspect
> > them all. Try that in Python.
> 
> I know python is dog slow and its far from perfect but it does have 
> clearer and more compact code than pascal as a result of ref counting 
> stuff and improving the base container types.

I do not agree. /me thinks Python looks messy.