NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/pascal/6670

Text File | 1992-11-17 | 4.0 KB | 85 lines

Newsgroups: comp.lang.pascal
Path: sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!rpi!utcsri!skule.ecf!torn!news.ccs.queensu.ca!slip209.telnet1.QueensU.CA!dmurdoch
From: [e-mail] (Duncan Murdoch)
Subject: Re: BP/TP OOP is missing something...
Message-ID: <[e-mail]>
Lines: 73
Sender: [e-mail] (Netnews control)
Organization: Queen's University
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Nov 1992 02:38:34 GMT

In article <[e-mail]> [e-mail] (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
[e-mail]