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

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

Path: sparky!uunet!utcsri!skule.ecf!torn!nott!cunews!revcan!software.mitel.com!kim!kim
From: [e-mail] (Kim Letkeman)
Newsgroups: comp.lang.pascal
Subject: Re: BP/TP OOP is missing something...
Message-ID: <[e-mail]>
Date: 18 Nov 92 13:10:57 GMT
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: MITEL Public Switching, Kanata, Ontario, Canada
Lines: 71
In-reply-to: [e-mail]'s message of 17 Nov 92 15:38:04 GMT

In article <[e-mail]> [e-mail] (Harry Kooijman,Peyt314a,3808) writes:

| Why is it that TP with objects does not have the capability to call the
| constructors when variables are declared?
<stuff deleted>
| When you dynamically allocate vectors and matrices this is very useful.
| If I forget to call the constructor or destructor I will be in for nasty
| debug times.

This is not as useful as it sounds. Dynamically allocating vectors and
matrices that are efficient requires specifying the size at
constructor time, i.e. the way it is done in TP. If you want
construction at declaration, then you have to grow your vectors and
matrices in real time and you lose all kinds of efficiency.

| This is why constructors in C++ have the same name as the objects.
| But what is more is that they allow for *multiple* constructors (and
| the compiler figures out which one to use).

Multiple constructors would be nice, and could be implemented in the
existing language, but the rules for handling different parameter sets
and/or optional parameters would destroy the "PASCALness" of TP. I.e.
if you really desire this facility, then use C++.

If, on the other hand, you are addicted to the incredible speed of the
TP compilers, then live with the burden of calling the constructors
and destructors yourself (not much of a burden IMO).

| It is mentioned that the compiler gets the burden of finding out all
| the details which routine to call when operators are overloaded (and
| also in other cases, such as the automatic generation of
| destructors).  Well, to my opinion its better to do so since the
| compiler does it faster than we can do. Ultimately we might have
| toolboxes full of objects we want add or subtract from eachother. If
| we want to do so its much easier to use the + and - then to call
| specific routines for each combination. If a certain operation can
| be interpreted for more than one (for example matrix * matrix, as
| Duncan pointed out) we have a choice: let the user determine the
| overloading. He can define his/her own version and pick the
| overloading he likes. Or we could pick the most popular overloading
| and put a warning in the manual/documentation!

Yes, well, this is one of C++'s strengths and IMO one of its greatest
weaknesses as well. These tool boxes you look forward to using will
have to be engineered by the same person to have any hope of being
reliable when being used together. Overloading introduces all kinds of
potential ambiguities with complex objects and this can take longer to
debug than it would have to call well named functions to do explicit
conversion between objects.

| TP with objects is a good product but it's missing some good
| portions of the object way of thinking, isn't it? Don't get me
| wrong: I'll be buying BP7 as well and probably using its OOP, but
| totally happy with it, no I am not. And that's the shame, since I
| regard Pascal higher than C++.

How can you argue so passionately for these itty bitty improvements to
a very well thought out OOP extension to TP and then in the next
breath say "probably use its OOP"? It seems to me that you are waiting
for perfection before using a facility that is already excellent. I've
written thousands of lines of code using the existing facilities and
believe me, it works.

To me, it has enough of the so-called "object way of thinking" to
allow the writing of completely isolated objects that can be used
without knowing anything about their guts. That's the whole point as
far as I'm concerned. The syntactic sugar you desire would be nice,
but wouldn't shrink most applications by more than a few lines of
code (again, IMO).
--
Kim Letkeman    [e-mail]