[fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

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

>> Absence of automatic construction/destruction of 
>> classes is very painfull and it can significantly 
>> degrade the
>> development process (i.e. smart pointers and RAII are 
>> impossible).
>
>Very painfull is a bit exaggerated :-)

Sometimes, it's. F.i.:

  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;

Eight lines instead of sixteen and much clearer. The compiler would
internally translate it to something like:

  procedure CopyFile(SourceFileName, TargetFileName: string);
  var
      s, t: TStream;
  begin
          // ---------- Start initialization block -----------
      s := nil;
      t := nil;
      try
          // ---------- End initialization block -------------

          s := TFileStream.Create(SourceFileName, fmOpenRead);
          t := TFileStream.Create(TargetFileName, fmCreate);
          t.CopyFrom(s);

          // ---------- Start finalization block -------------
      finally
          s.Free;
          t.Free;
      end;
          // ---------- End finalization block ---------------
  end;

I guess it's much alike to what happens with AnsiStrings.

>> Are there any plans for serious language
>> extensions in this way for "post 2.0" releases of FPC ?
>
>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. 

And you can still declare "normal" variables with explicit
destruction. It's not like Java and other languages that forces you to
use automatically disposed variables. You can choose.

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?

Another option: would it be possible to "plug in" the compiler to add
user extensions?

>Moreover it will be a Delphi incompability.

* You aren't forced to use this feature. You can be compatible simply
not using it. 
* There are other FPC features that aren't present in Delphi like
overloaded operators. 
* It's better to be incompatible because you have more features than
because you have less features. 
* Delphi is going to implement something like this anyway to keep its
compatibility with its .NET version.

>> P.S. The simpliest proposal for syntax for auto construction/destruction
>> could be like (maybe with some restrictions
>>      on constructors/destructors):
>> 
>>  Procedure Something;
>>  Var T:tMyClass;Auto;
>>  Begin   <- T auto created here
>>     ...
>>     If ... Then Exit; <- T auto destructed here
>>     ...
>>  End;    <- T auto destructed here
>> 
>>  P.P.S. The "auto" modifier should affect only stack 
>> variables.
>>         There's no great need of this for global vars.
>
>I don't like it. Either go the full way (like e.g. with ansistrings) or
>don't go there at all. This is a hack.

Why? Its implementation is straight-forward, simpler than ansistrings'
and eliminates all that distracting memory plumbing code. 



--
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.