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

Text File | 1992-11-17 | 4.2 KB | 95 lines

Newsgroups: comp.lang.pascal
Path: sparky!uunet!clarkson!news
From: [e-mail] (Harry Kooijman,Peyt314a,3808)
Subject: Re: BP/TP OOP is missing something...
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: sun.soe.clarkson.edu
Organization: Clarkson University
References: <[e-mail]>
Date: Tue, 17 Nov 1992 15:38:04 GMT
Lines: 82

From article <[e-mail]>, by [e-mail] (Kim Letkeman):
> In article <[e-mail]> [e-mail] (Brad S. Choate) writes:
>
> | When will Borland implement operator overloading for Pascal OOP???
> | They boast that their product is a good way to learn OOP, but
> | provide no way of teaching operator overloading!  I dare say they
> | should not call it "professional" until then.  IMHO, for OOP, stick
> | with C++ until Borland gets their act together (correction...
> | SERIOUS OOP).
> |
> | Don't get me wrong... I love Pascal, but I hate that it doesn't
> | benefit from all the goodies C++ has gotten over the years!
>
> Operator overloading is just one tool in the object oriented toolbox.
> One very notable book on the subject "Object Oriented Software
> Construction" by Bertrand Meyer mentions it in passing as: "no more
> than a syntactic facility which relieves programmers from having to
> invent different names for different implementations of an operation
> and, in essence, places the burden on the compiler." See page 39.
>
> <stuff deleted>
>
> TPW is as professional as any compiler I've ever seen. My guess is
> that it completely smokes all but the very best C++ compilers in
> overall quality and utility (that is, ability to do useful work.)
>
> I would suggest that you figure out what it is that you really want to
> get out of OOP rather than worrying about this or that missing
> C++ facility in a PASCAL compiler.
> --
> Kim Letkeman    [e-mail]

Why is it that TP with objects does not have the capability to call the
constructors when variables are declared? And when an object goes out of
scope it should be destructed automatically. For example:

Function DoSomethingWithD;
Var D:DoubleObject(1.2);
Begin
  ...
  Do something with D
  ...
End; {and here D gets destructed}

This makes using objects not any different than any ordinary variable
type, and a lot more easier to maintain (If I want to delete the use
of the DoubleObject it is sufficient to delete the declaration and
all the references to D, and I don't have to worry about a constructor
and destructor).

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

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!

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

Harry
--
Harry Kooijman: Rigorous dynamic distillation simulation.
Dept. of Chemical Engineering, Clarkson University, Potsdam NY 13699.
[e-mail]