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

Internet Message Format | 1992-11-18 | 5.4 KB

Xref: sparky comp.lang.pascal:6678 comp.object:4254
Newsgroups: comp.lang.pascal,comp.object
Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
From: [e-mail] (Markku Sakkinen)
Subject: Re: BP/TP OOP is missing something...
Message-ID: <[e-mail]>
Organization: University of Jyvaskyla, Finland
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Nov 1992 10:45:36 GMT
Lines: 91

(This discussion comes from comp.lang.pascal.   I thought cross-posting
to comp.object might be appropriate at this point.)

In article <[e-mail]> [e-mail] (Duncan Murdoch) writes:
>In article <[e-mail]> [e-mail] (Robert Beauchaine) writes:
>> ...
>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. [...]
> ...
>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.

In a way, "you cannot eat your cake and have it too".
If one wants to do fully-fledged OOP, one cannot fully conserve all of
Pascal's original principles.  Most importantly, OOP implies information
hiding and "decentralised design":  you must accept that other classes
are doing things behind your back (or behind the scenes), and you don't care.
Some initialisation and (less often) finalisation needs can really be
an internal affair of a class, about which its clients should not bother.

There is at least one spot in standard Pascal where automatic initialisation
happens: file variables (admittedly a murky part of Pascal semantics).
After _only_ declaring a file variable, it is also initialised to
a well-defined state such that you cannot do any other operations
before calling 'reset' or 'rewrite'.
I would guess that good Pascal implementation may also initialise
pointer variables to NIL so that using them before assignment
will not cause catastrophic effects.

Class objects are often similar to file variables in that allocating
raw memory is not sufficient for applying ordinary operations immediately.
Perhaps some fields of each object must be given particular initial
values in order to establish the class invariant on which all other
operations except the constructor(s) depend.

Often, a variable-sized chunk of dynamic memory must be allocated
"behind the scenes" during initialisation (or at other times).
Such cases are the most common cause of the need for finalisation:
since neither Pascal nor C++ support garbage collection,
that memory must also be released.

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

The idea is that all other uses of an object happen between its
initialisation and the finalisation;  of course you cannot change
an object after it has been destroyed.  Your matrix example would
be much easier to do in Simula or C++ than Pascal, because they allow
variables to be declared even within blocks (not only in function and
procedure headers), and they allow also initialisation parameters.
In any flavour of OO Pascal without such parameters, the constructor
of a general matrix class (i.e. without fixed dimensions) would most
naturally create only a "handle" for an actual matrix.

Of course, automatic construction is optional (e.g. in C++):
the class designer is not required to define any constructors or destructors
if he/she does not perceive real need for them.
(Well, in C++ you sometimes had better write a do-nothing virtual destructor
to be safe, but that is a special quirk of that language.)

----------------------------------------------------------------------
Markku Sakkinen ([e-mail])
       [e-mail] (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------