Re: Syntax for tagged record types and class types

[stt@houdini.camb.inmet.com (Tucker Taft)]

Matthew Heaney (mheaney@ni.net) wrote:

: In article <33830D58.6D8F@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote:

: >So do I. And if tasks and protected types provide that kind of notation,
: >why should this not also be true for other constructs ?

: Agreed.  Selection should be consistent for all objects.  The "principle of
: uniform reference," and all that.

Prefix notation, by which I mean <object>.<operation>, is reserved in
Ada 95 for calls on "synchronizing" operations.  The prefix object
is the one controlling the synchronization.  Hence, prefix notation is
used for task entry calls, and protected operation calls only.  
In each of these cases, the prefix object is very special -- one
must enter the synchronization domain of the prefix object before the
operation is performed.  Even if there are multiple parameters of
the same task or protected type passed to the operation, the synchronization
is associated only with the prefix object.

For non-synchronizing operations, all parameters are treated symmetrically, 
and so the "principle of uniform reference" would argue that all such 
parameters belong inside the parentheses, rather than dangling out front.

Furthermore, look at the nasty syntax in a language like C++ for talking
about the "mode" of the implicit, prefix parameter.  The word "const"
is floating about in some unintuitive place in the function declaration.

Finally, look at the nastiness associated with binary operators in C++
(and the complete lack of such binary operators in Eiffel and Java).
In Ada 95, the "uniform reference" principle of treating all parameters
uniformly eliminates all the kludgery associated with binary operations.

Note that I am being a bit facetious here.  There certainly are some 
advantages (and disadvantages) to using prefix notation.  However, the 
notion that a single phrase like "uniform reference" can be used to 
justify one choice over another is a bit of a stretch in my view...

: ...
: Gee, isn't armchair language design fun?

You bet.  Of course, if you really want to have fun, try achieving
international consensus on your design ...

--

For what it is worth, my advice is to avoid using all the fancy
syntactic features of your favorite OO language and stick with old
function and procedure notation almost everywhere.  Constructors,
aggregates, and allocators should only be called inside "factory" routines. 
Operators should be reserved for numeric-ish types like complex numbers,
vectors, and matrices.  User-defined selectors, array indexers, etc.,
should be avoided; even using predefined selectors and array indexing should
be confined to the implementation of query functions.  Use procedures 
(aka void-returning functions) to change objects, and use functions to 
query objects.  Use a "factory" function or procedure to create new objects.

This approach will keep your abstraction "clean" and relatively language
neutral, making it amenable to use with CORBA, (D)COM, etc., and other
multi-lingual technologies (and people!).  All of the "fruit salad" provided
by some OO languages saves only a few keystrokes in most cases, and
can significantly interfere with the ease with which others can pick
up your code and understand it, reuse it, and enhance it.

All the above IMVHO...

: --------------------------------------------------------------------
: Matthew Heaney
: Software Development Consultant
: <mailto:matthew_heaney@acm.org>
: (818) 985-1271

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA