Re: Real OO

[mbk@caffeine.engr.utk.edu (Matt Kennel)]

Robert A Duff (bobduff@world.std.com) wrote:
: In article <4n066d$6gl@gaia.ns.utk.edu>,
: Matt Kennel <kennel@msr.epm.ornl.gov> wrote:
: >I know this is flame bait,

: Flame bait?  Nah, just a reasonable technical opinion.  I hope this
: doesn't look like a "flame"?

: >... but in my opinion, if you're going to have
: >a single 'dispatching'/'controlling'/'tagged' operand you might as well
: >bite the bullet and specifically designated it like Eiffel does. 
: >
: >    Op(a,b,tagged c) <->  c.Op(a,b)

: OK, but Ada allows more than one of them to control the dispatching.
: It's not multimethods -- they all have to have the same tag.  But, to
: me, Union(This_Set, That_Set) ought to make it look like This_Set and
: That_Set have equal rights -- i.e. it ought to look symmetric.
: This_Set.Union(That_Set) seems inelegant to me.

This is a special case, because in general a compiler wouldn't know
that "Union(X,Y)" is the same as "Union(Y,X)"---for all it cares,
you can spell "Union" as "MagicFrobozzSubroutine".

Personally, I advocate an alternate syntax for method
calls single dispatching languages:

        '(x routine y)' is an alternate way of saying 'x.routine(y)'


`A spoonfull of sugar makes the medicine go down'
      

: Also, what do you make of Ada's dispatching-on-result?  E.g.,
: Union(This_Set, Empty_Set), where Empty_Set is a function, and this
: dispatches to the "right" Empty_Set based on the tag of This_Set?  Maybe
: that's a silly example, since we know what union with the empty set
: means.  Maybe Union(This_Set, Singleton(37)) is a better example, where
: Singleton takes an Integer (not dispatching on that Integer), and
: returns a set.  Or maybe,

:     Intersection(Union(Singleton(37), Singleton(24)), This_Set)

: where the tag of This_Set controls which Singleton operation to dispatch
: to.

Whoa!  Neat.  I think...!?

And how is it supposed to know that Singleton has anything to do
with Sets and has a 'dispatch axis' along the type of This_Set?

Suppose the "This_Set" variable was type SET_A, but you wanted to
create a variable of type SET_B from the Union?

Is it only me but does this feel a bit too much like "spooky action
at a distance"? :-)


: What about operations that belong with the type, but don't depend on any
: particular object of the type?  In Smalltalk, it would be a class
: method.  Ada's packages are like Smalltalk's class objects (although
: rather less dynamic).

You can put those into classes just fine. After all, these are what 
constructors are anyway.  I prefer that Eiffel & friends really ought to
have been called "class-oriented" langauges, 
you cannot attach particular methods to particular *objects* of course! 
You can denote methods for classes, and particular objects can be members of
certain classes. 

: >Writing things as Op(a,b,c,d,...) does seem to imply multimethods to
: >most people.   (It did to me.)

: Perhaps.  I don't think the Ada Reference Manual gives that impression.



: >After peeling away the surface Ada has more similar semantics to
: >Eiffel than admitted---yes there really is
: >such a thing as a 'class(Eiffel-usage) interface' of a certain
: >type, even though "theoretically" interfaces are just properties of
: >packages which don't have anything to do with types. 

: Admitted?  Yes, Ada and Eiffel are quite similar, in many ways.  I will
: certainly admit that.  There's a notational difference, in that the
: dispatching operands aren't syntactically distinguished in Ada.

The difference that I was pointing out is that Ada does indeed have
the notion of a 'type interface' (mumble something about primitive operations
of a blah blah blah), but it is implicit, whereas Eiffel makes it plain as day.

In Ada you joyfully write 'packages' and 'package interfaces' but you still
have to end up thinking about types and type interfaces too. 

I feel Eiffel is 'more honest' in this respect. 

: There
: are (fairly minor) functionality differences.  And Ada doesn't need
: "system validity checks".  One fairly important difference is the
: distinction that Ada makes clear between a particular class/type in the
: hierarchy, vs. all class/types descended from there -- other languages,
: including Eiffel and C++ obscure that distinction. 

This is an intentional decision of Dr Meyer.  C++?  It sort of came out
in the wash. 

I prefer Sather which more explicitly distinguishes the two, like Ada.

: - Bob