From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
Subject: Re: BP/TP OOP is missing something...
Organization: Queen's University
Date: Wed, 18 Nov 1992 02:38:34 GMT

In article <10773@vice.ICO.TEK.COM> bobbe@vice.ICO.TEK.COM (Robert Beauchaine) writes:
>  This whole topic falls under the scope of garbage
>  collection, which is considered by many programmers an extremely
>  important part of a language.  And pascal already does it all the
>  time anyway.  What happens to the local variables allocated on the
>  stack when a function begins or ends?  They are created/destroyed
>  by the compiler, which knows knows exactly how to perform these
>  tasks.  The only difference between
>  objects and the predefined data types is that *you* have to tell
>  the compiler exactly how to build or get rid of the objects.  You
>  should not have to tell the compiler _when_ to do so.  It seems to
>  me the current object construction/destruction methodology is the
>  departure from the norm.

No, I think there's a difference between allocating variables and 
initializing them.  The compiler is perfectly capable of automatic 
allocation of objects when they're local variables, and it'll automatically 
free up the storage when it goes out of scope.

However, calling a constructor for an object is akin to initializing it.  
As far as I can recall, there aren't any cases in Pascal where variables 
are initialized without explicit action by the programmer.  In TP, there are 
"typed constants", but as you mentioned, they usually aren't a good solution.
There are also variables that get initialized by the init sections of units, 
but the only one that doesn't require explicit mention is System.

Maybe allowing automatic initialization would be a good change.  It 
would certainly save a line here and there if I could declare a local 
variable with an initial value, e.g.

  procedure myproc;
  var
    i : integer = 0;
  begin
    while i < 5 do ...

and have the same effect as

  procedure myproc;
  var
    i : integer;
  begin
    i := 0;
    while i < 5 do ...

But a change like this wouldn't gain me anything.  I wouldn't be able to do 
anything that I can't do now.  The only advantage is that I'd save a bit of 
typing.  

On the other hand, it would be a far reaching change that would 
affect the language in lots of little ways.  Right now, declarations 
are declarations, they aren't executable statements.  You're suggesting 
that the distinction be blurred.  

>  This is exactly why I like the C++ approach.  With automated
>  construction/destruction, operator overloading, etc, objects are
>  much more seamlessly integrated into an application as extensions
>  of the basic data types.  Once the class is properly defined, the
>  programmer never has to consider the objects as anything except
>  predefined atomic stuctures again.

On the other hand, it seems that it would be rather inefficient in lots of 
code.  For example, I often write routines that need to do calculations 
before they can call the constructor for an object; if it had already been 
constructed, would I have to destroy it before changing it?  A simple 
example would be reading a matrix from a file:  I might read a line to get 
the matrix dimensions, construct an appropriate matrix, and then read the 
data into it.  How are situations like that handled with automatic 
constructors?  Or is the automatic construction optional?  If so, that just 
leads to code equivalent to the TP code.

Duncan Murdoch
dmurdoch@mast.queensu.ca