Re: Choice of OO primitives in Ada95

[jsa@organon.com (Jon S Anthony)]

In article <Dn22M0.G0D@assip.csasyd.oz> donh@syd.csa.com.au (Don Harrison) writes:
> Robert A Duff writes:
> 
> :In article <Dn0FqH.8Cw@assip.csasyd.oz>,
> :Don Harrison <donh@syd.csa.com.au> wrote:
> :>package X is
> :>  type MARRIAGE is tagged ...
> :>  type PERSON is tagged ...
> :>  type UNIVERSITY is tagged ...
> :>  type GOVERNMENT is tagged ...
> :>  type ELECTORATE is tagged ...
> :>  type ADDRESS is tagged ...
> :>
> :>...
> :>end X;
> :>

> :>Each abstraction is related to the previous one but isn't necessarily
> :>related to any other. As I understand it, the language rules dictate
> :>that each of these abstractions must be in the same package.
> :
> :No, they don't have to be in the same package (and as you say, probably
> :should not be).  Could you explain what you mean -- why do you think
> :that all of the above types have to be in the same package?
>
>  I don't have an RM available but quoting you (25.1.96) on the
> subject of dispatching operations in response to Arcadio A. Sincero:
> 
> > >As a matter of fact, the only indication that TPerson's Walk "belongs to
> > >it" is that TPerson's Walk has a TPerson parameter.
> 
> > That, plus the fact that it's in the same package.
> 
> So, if you want all of the operations to be dispatching (primitive), then the
> tagged types must also be in the same package.

What in this in anyway could even _possibly_ be construed in the
course of even the most tortuous path of illogic to be saying _all_
the types _together_ need to be in the _same_ package?  Hmmmmmm????


>  In the same thread, Jon S Anthony went on to say that
> non-dispatching operations using tagged types were those defined in
> different packages to those types:
> 
> > Just to add one more bit (completely beating it to death...), it is also
> > legal to have a subprogram with operands of both types as long as it is
> > not in the package where the two types are declared.  Of course such a
> > subprogram is not primitive and will never dispatch (assuming it has no
> > other controlling operands).

See above (possibly even more so).


>  Dispatching or not dispatching depending on where an operation is
> defined is not what you would call consistent.

Why not?  Seems pretty simple really.  And it allows for non
dispatching operations to be constructed if they have a closer match
to the desired semantics.  And why should operations that are closely
tied to the semantics of a type (basically the intent of primitive
operations) be definable anywhere?  That sort of thing leads pretty
quickly to inscrutable structures.  (I believe that Dylan does allow
this sort of thing, but there has been disagreement on how "wonderful"
it is.)


> A couple of other gripes:

>  1) Why should you have to specify that a type is 'tagged'? Can't
> the compiler work that out for itself? eg. by seeing whether the
> type is extended elsewhere. The developer is forced to worry about
> what should be an implementation issue.

Ahhh, the ol' clairvoyant compiler.  You are on a roll.  What if the
type is not extended?  This sort of comment might make sense if you
were discussing a language where the only kinds of types available
were "classes" (actually, it would not even make sense there as then
it would be irrelevant).  But you aren't.  Of course you can decry
this fact, but that is another matter altogether and irrelevant given
the current context.  Also, given the context, it is very much the
case that "tagged" is _not_ simply an implementation issue.  Flagging
a particular type as one which is extensible and supportive of dynamic
polymorphism can be argued to be a "good engineering" tradeoff.


> 2) Similarly, why should the developer have to specify that an
> operation dispatches (classwide operations)? Presumably, you're
> aiming for quicker execution, but compilers could perform a certain
> degree of optimisation eg. If it knows the type is not extended
> anywhere, there is no need to dispatch. There would also be
> situations where the specific variant of an inherited type is known
> eg. following an explicit assignment from an entity of that type.

This is just plain wrong - on several accounts.  First class wide
operations do not dispatch (they have uses more akin to a "generic
method" in CLOS, though clearly more restricted).  Second, _all_
primitive operations are dispatching operations.  The "developer" does
_not_ specify that an operation dispatches (other than simply
including it as a primitive operation of a tagged type).  Third,
optimization is irrelevant _to the semantics_ of whether any actual
_invocation_ dispatches.  Sans optimizations a primitive operation
dispatches iff it has class-wide actuals for the operation's
controlling parameters - the compiler _always_ knows when a particular
call of an operation dispatches.  Fourth, optimization is also
(mostly) irrelevant for making the design choice of keeping instances
of dynamic polymorphism a local rather than global issue.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com