[fpc-devel] Re: [fpc-l] type discussion

Marco van de Voort marcov at stack.nl
Thu Jun 2 18:34:20 CEST 2005

> Michael Van Canneyt wrote:
> > This is only 'logical' if the hypothesis
> > 
> > "productivity is inversely related to the syntax verbosity"
> > 
> > is correct.
> And it's not.
> What is correct is "productivity is directly related to the number of 
> separate language constructs developer has to put in program to acomplish 
> the task"

True. But the problem is that the "task" is not a constant. _If_ you really
try to exploit this feature, and increase your programming speed (by not
having to track object age and owner), you will have to deal with
irregularties in deallocation (GC storms), null pointer exceptions etc.

> Or lack of standard libary supplied container 
> apropriate for a task requires programmer to develop his/her own or to adapt 
> something less usable.

Partially true yes. However the only reasonable solution for that is
generics I think.
> So here is some little idea which seems to me Pascalish enough to be considered:
> how about new keyword: local
> Class variable declared local will be automatically freed upon every exit 
> from the scope (i.e. something along the lines of implicit try/finally for 
> some builtin types).

No. Inconsequent. 

I think you are totally on the wrong track if you want to try to solve this
with language.

There are only two solutions :
1) go fully automated
2) have only the minimum on base automated types (e.g. strings, I don't count
variants, since they are for a specific purpose)

Any patchy solutions will only go against this. Most allocations aren't
limited to a simple scope anyway. Since not everything is an object, there
is a lot less object creation going on.

Even dynamic arrays were somewhat doubtfull, but finally mostly added
because of Delphi compat.

More information about the fpc-devel mailing list