On Thu, 2 Jun 2005, Sebastian Kaliszewski wrote:
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"
Inversely related, I assume you want to say :-)
So, for example, need to put separate finally block to free memory means
additional few constructs. Or lack of standard libary supplied container
apropriate for a task requires programmer to develop his/her own or to adapt
something less usable.
Geeintg rid of end in begin / end wont help much (as they can;t be separated,
they count as single construct).
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).
While I can see the use, there are all kinds of problems associated with it.
So instead of
Var
S : TStringList;
ManagedVar // or whatever. All that goes here is freed again by the compiler.
S : TStringList;
begin
S:=TStringList.Create;
// code here
end; // Compiler frees S here.
But the compiler needs to check many things:
1. Initialize the S with Nil.
2. Check that S is assigned only once during the lifetime of the
procedure.
This is actually a bigger restriction than you might think,
unless you want to introduce reference counting.
3. Put a try/finally block and generate a call to S.Destroy at the end.
It must also catch any errors that may occur when s.destroy is
called. For classes, this danger is very real; For ansistrings it is
not (well, very small)
4. It cannot assign S to anything, since that could mean that the
lifetime of S could be prolonged. The alternative is again again ref.
counting.
This is not so easy, and reference counting is always a mess...
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
