[fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 15:56:07 +0200 (CEST), marcov at stack.nl (Marco van
de Voort) wrote:

>>   procedure CopyFile(SourceFileName, TargetFileName: string);
>>   var
>>       s, t: TStream;
>>   begin
>>       s := TFileStream.Create(SourceFileName, fmOpenRead);
>>       try
>>           t := TFileStream.Create(TargetFileName, fmCreate);
>>           try
>>               t.CopyFrom(s);
>>           finally
>>               t.Free;
>>           end;
>>       finally
>>           s.Free;
>>       end;
>>   end;
>> 
>> Imagine you could write:
>> 
>>   procedure CopyFile(SourceFileName, TargetFileName: string);
>>   auto
>>       s, t: TStream;
>>   begin
>>       s := TFileStream.Create(SourceFileName, fmOpenRead);
>>       t := TFileStream.Create(TargetFileName, fmCreate);
>>       t.CopyFrom(s);
>>   end;
>
>(besides MVC's comments):
>
>This is an exception already, but worse  the example is crafted so that
>there is no discrimination where the error source is. This is rare.

This is for me very natural code. It was written by heart, but I have
a lot of very similar code.

>Typically, a skeleton source as above would have EXCEPT clausules that
>improve errorhandling.

This was indeed an example. But again, the code is reallistic, and the
behaviour of a possible exception ("file not found 'c:\aaa.txt'") is
very acceptable and similar to other classes that I have written
myself. 

>> I guess it's much alike to what happens with AnsiStrings.
>
>Ansistrings don't work with exceptions. 

Then, what happens with locally allocated strings if an exception
raises in the middle of a function? If there is no code to catch the
abnormal exit, the memory will be leaked!

>> >No. There is a big resistance against such features, mostly because
>> >the benefits are superficial, and the idea is unpascallike.
>> 
>> What I like of Pascal is clarity. I feel much more pascal-like the
>> eight lines version than the sixteen lines one. 
>
>Clarity is not the same as terseness. Pascal is also consistency and safety.
>There is too much that can go wrong with this kind of mechanisms, 

I'm afraid you're right here. I didn't pretend it to be safe.

>The safety of the automated type depends on the possibilities.
>It would require a lot of extra checks and changes to make this even halfway
>safe. 

>> I wonder what "big resistance" means exactly. It could be that none of
>> FPC developers wants to spend his time with this feature. But what if
>> someone implemented it as a patch? Would it be rejected?
>
>I think so, yes. 
>
>> Another option: would it be possible to "plug in" the compiler to add
>> user extensions?
>
>Not really. Not for language related stuff. Maybe stuff like optimization
>could be some what pluggable, but I doubt it. I think it would also
>immensely increase (the already quite high) mem requirements.

I'm sorry to read that (see my response to MvC) but thank you for the
clarification. There are still ways to ease memory management without
compiler support, but other improvements need plug-in support... or a
rewrite :-(

>No. More features is not better in languages. 

I guess it's a matter of opinions :-)

>> * Delphi is going to implement something like this anyway to keep its
>> compatibility with its .NET version.
>
>Delphi.NET is IMHO a project relatively unrelated to Delphi, since it 
>breaks code running since TP3.

I meant that sooner or later Borland will update its native code
compiler, and then much of the features introduced in .NET version
will be ported.

>> and eliminates all that distracting memory plumbing code. 
>
>No. It only saves that in a few exotic cases. If you want to have that all,
>you need to change languages, and go to something truely automated. Be it
>Oberon (aka Component Pascal for the .NETies), Smalltalk, Java, C# or
>Delphi.NET)

Fully automated language usually don't allow explicit memory
life-cycle control. I think that having both options to choose from is
not asking for too much.




--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to "nico" at the same domain for direct email.