Re: Real OO

[bobduff@world.std.com (Robert A Duff)]

In article <4nadoc$pa7@gaia.ns.utk.edu>,
Matt Kennel <kennel@msr.epm.ornl.gov> wrote:
>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".

I don't demand that the compiler know Union is commutative.  I just ask
that I can declare a Union that treats its arguments symmetrically, with
respect to visibility and syntax.  "-" isn't commutative, but X - Y, to
me, looks like X and Y have equal rights -- the idea that X knows how to
subtract Y from itself seems silly to me.

>Personally, I advocate an alternate syntax for method
>calls single dispatching languages:
>
>        '(x routine y)' is an alternate way of saying 'x.routine(y)'

What if "routine" has three args?

>`A spoonfull of sugar makes the medicine go down'

Indeed.  And a spoonful of vinegar?  ;-)

>:     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...!?

;-)

This is not a major feature, but I think it *is* kind of neat.

>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?

Singleton is dispatching-on-result if and only if it is declared in the
same package as Set, and has a return type of Set.

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

Then you would use a class-wide operation, instead of a dispatching
operation.

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

Distance?  It's only within a single statement, so it's not so horrible.

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

True.  It seems kludgy to me, in C++, that constructors are part of the
same class.  Smalltalk is more elegant, in that it has a separate class
object, and the constructors belong to that.  Ada is similar, in that
constructors are part of the package, not part of every object of the
type.  Smalltalk class objects are like Ada packages, in this sense,
although Smalltalk class objects are much more dynamic, and therefore
more powerful.

>...  I prefer that Eiffel & friends really ought to
>have been called "class-oriented" langauges, 

Agree.

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

But the syntax "X.Foo(Y)" or "x foo: y" makes it look like Foo is
contained within X, which is wrong, since all X's share the *same* Foo
for the whole class.

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

Eiffel makes *something* plain as day.  Namely, the interface of all ops
that take that class as the *first* argument.  There's nothing in Eiffel
that makes "plain as day" the fact that various random operations take
class C as the *third* argument.

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

True.

- Bob