[fpc-devel]Proposal for audo-destructors

[Marco van de Voort]

> On Sun, 12 Sep 2004 13:07:24 +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.
Typically, a skeleton source as above would have EXCEPT clausules that
improve errorhandling.

This kind of constructs are extremely common in e.g. Java, but there nearly
everything is an object (strings inclusive)
 
> I guess it's much alike to what happens with AnsiStrings.

Ansistrings don't work with exceptions. 
 
> >
> >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, and too
little to be truely gained.

MvC already refered to earlier "what if"'s we had on core about this kind of
functionality. (the one that only "shortens" a certain syntax, aka syntactic
sugar)

It was deemed a better solution to have the IDE (e.g. Lazarus) autogenerate
the above skeleton from the compiler.

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

No you can't. 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.

> >Moreover it will be a Delphi incompability.
> 
> * You aren't forced to use this feature. You can be compatible simply
> not using it. 

No, but I'm supposed to provide support and help with bugreports. This
is an ugly can of worms for unsuspecting users. Even intermediate programmers
could fall easily for this (since an auto near the top is easily missed).

> * There are other FPC features that aren't present in Delphi like
> overloaded operators. 

However they nearly _all_ improve functionality, not merely cut a bit of
typing.

The only two exceptions is the exit(x) extension and the use of ^basetype;
as array (Cish). However these are extremely common.

> * It's better to be incompatible because you have more features than
> because you have less features. 

No. More features is not better in languages. 
(and neither in Word Processors btw. Exhibit A: Word). A syntax must be
orthogonal, systematic and intuitive.

Shorter syntax also isn't automatically better (Examples enough, C, Perl are
known for their terse and unreadable syntaxes)

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

Delphi.NET is more the Java way, and totally different rules apply to it,
whether you like or dislike it. See also 
http://www.freepascal.org/faq.html#dotnet

for a short (but still unpolished) summary.
 
> >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'

Yes, but ansistrings are safe. This isn't. Moreover ansistrings have an
important issue that couldn't be done earlier ((nearly) unbounded strings,
that are very native). This only saves typing.

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

However then you pay the price in speed, startup time, memory footprint,
runtime versionitis and non native feel of the avg GUI. (read: Swing, but
all have this kind of, since they try to hide the native OS too much)