Re: Eiffel and Java

[jsa@alexandria (Jon S Anthony)]

In article <E02IMv.I9M@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Matthew Heaney writes:
> 
> :Ada's type mechanism accomplishes the equivalent of pre- and
> :post-conditions, and you don't seem to mind their inclusion in Eiffel, so
> :that can't be it.
> 
> It's true that Ada's typing does accomplish some of what assertions offer 
> but assertions are more general (and useful) than that. For example, it is

Right.


> :About subprogram calls.  C++ or Eiffel programmers call objects this way:
> :
> :   theStack.push (5);
> :
> :and Ada programmers do this
> :
> :   Push (5, On => The_Stack);
> :
> :It's not a moral issue which way is better, just a difference in syntax. 
> :They both do the same thing.
> 
> Yes - not something to lose sleep over. The Ada syntax can be justified
> because it is a hybrid language. IMO, the dot notation is preferable for

Actually, while it is not multiple dispatching (multi-methods), the
syntax does indeed allow several little niceties that the dot notation
flubs.  It is this stuff that is the "justification" - not any so called
"hybrid" aspects.


1) the dot notation makes the operation _look_ like a field of the object but
   in general this is _not_ true (some OOLs do have per object methods but
   not the usual ones like Eiffel, C++, Sather, etc...)

2) the dot is asymmetrical and makes many cummutative operations look
   lopsided.  For example, Union(set_a, set_b) = Union(set_b, set_a), and
   the notation should reflect this (infix would be even nicer here).  But
   in "dot land" you have set_a.Union(set_b) which looks like set_a _has_
   the operation and is "special" somehow.

3) the function notation allows Ada to dispatch based on the _result_ of
   parameter which is a function call.  Or has the function dispatch to
   the right thing based on the other parameters.  Bob Duff gave a couple
   of nice examples of this:

   Union(My_Set, Singleton(X)), where Singleton's dispatching is the
   controlling _result_ and _not_ the argument (with X being an integer
   or something).  Here, Singleton would dispatch to the proper version
   based on the tag of My_Set.

   (Singleton(X) + Singleton(Y)) * My_Set, where "+" is union and "*" is
   intersection.  Here the tag of My_Set would control the dispatch of
   the Singleton operations.

> it is special. The downside is that symmetric operations do not
> appear as such. Well, not really, because you can always regain it
> by inventing another class for performing symmetric operations:
> 
> eg. class SET_OPS
>       ...
>       union (a, b: SET): SET is ...
>       intersection (a, b: SET): SET is ...
>       ...
>     end

Well, sort of...  Seems like pretty extraneous futzing to accomplish
such a simple and ordinary thing.


> In any case, truly symmetric operations are relatively few, IMO.

Actually, if you stated this as "for my areas, symmetric ops are
relatively few", I could buy it.  But in general symmetric operations
are all over the place.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com