Re: OO dot notation

["Pat Rogers" <progers@classwide.com>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1029357303.33848@master.nyc.kbcfp.com...
> For all those who have been arguing that Ada would be much
> more successful if it allowed the object.method() syntax,
> it might be interesting to check out some of the goings on
> in comp.lang.c++.moderated, in the 'Guru of the Week #84'
> threads. Many of the C++ cognoscenti are coming to the
> conclusion that the method(object) notation is superior,
> and indeed that as few functions as possible should be made
> methods of a class.

Interesting article (I only read the first).  A few comments...

1) I take your meaning in the above, I think. You're saying that
the distinguished receiver syntax is not so big a selling point
because there are good reasons (at least, according to the
article) not to make every function a member of a class and in
those cases the notation will not be available anyway.  Right?

As you know, the Ada syntax doesn't affect in any way whether or
not a procedure or function is a "member function".  It's all a
matter of where the subprograms are declared and with what
parameter and result types.  But the article is not discussing
syntax anyway.

2) I would argue that the article is really about abstract data
type programming.  ADT's have, of course, been around for a long
time and have always been fundamental to Ada.  So the design
choices described by the article and the position taken by the
author are not new to the Ada crowd.  (I hope that does not come
across as condescending; it is not meant to be.)  Booch's first
Ada (83) book discussed this years ago, when Ada only had ADTs
and a limited form of inheritance: you only made subprograms
primitive if they required direct access to the representation.

3) The design decision certainly applies to OOP objects as well
as to ADT objects, since they are the same thing in so many ways.
In Ada, this is especially so because the language has explicit
class-wide types and class-wide subprograms.  The decision of
what subprograms should be class-wide instead of primitive to a
specific type is based on the criterion described in the article:
can we reasonably write this subprogram in terms of the existing
primitive operations (using dynamic dispatching)?  If so, we do
indeed make a much more flexible subprogram and increase
encapsulation without loss of performance.

4) OK, I cannot entirely resist the temptation to say that the
article indicates there may yet be hope for those class-oriented
language guys!  :-) :-)

Thanks for pointing out the thread!

Best regards,

--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability
Analysis
(281)648-3165                                 Software Fault
Tolerance