Re: Real OO

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

Don Harrison (donh@syd.csa.com.au) wrote:
: Yes, I confess my knowledge of OO languages is fairly narrow. I guess I'm very
: selective about which I bother looking into especially when I know how well
: designed Eiffel is. Some claim that Sather is good and I would like to know
: more about it but, from my understanding, it has no assertions and has (or is
: about to have) a separate module mechanism. 

It does have pre/post and invariants stolen shamelessly from Eiffel, in
addition to Ada-like 'in', 'out' and 'inout' parameter modes which are
vaguely preconditionish.  (This made iters and interfacing to Fortran more
natural and orthogonal). 

It doesn't yet have them in abstract supertypes; there was some original
trepidation because of some technical problems (not in implementation but
in undesirable consequences) but I think they may be in the upcoming 1.1
release. 

Note that they are 'inherited' through implementation inclusion, so you
already get a large fraction of the Eiffel benefits. 

: If this is true, it seems likely
: the designers have missed the importance of assertions and uni-encapsulation
: in an OO model.

No.  Sather's locus of encapsulation is the class, exactly as Eiffel.  It has
a privileged distinguished dispatching member, just like Eiffel (but it
does have overloading unlike Eiffel). 

Sather is much more like Eiffel than you believe.  Differences include:
(only the first two are major)

   *  distinguishes implementation inheritance from interface subtyping
      (Yeah the thing that Java does). This makes feature inheritance
      and renaming a bit simpler. 

   *  special iterator constructs  (very cool!)

   *  Allows post-hoc supertyping.  (put a new abstract class I wrote
      'over' existing classes, including library classes)

   *  different kind of type inference (more limited than 'like', but
      allows automatic declaration at first assignment)
   
   *  feature overloading based on static argument types

   *  more limited range of definable infix operators

   *  no class specific export controls

   *  parameter modes

   *  'partial classes' and 'stubs' --- enforced mixins 
      for implementation inheirtance

   *  user-definable [] -- left hand assignment distinguished from
      right hand fetch.

   *  differences in interfacing with external languages, C and Fortran. 

The supposed module mechanism is quite lightweight and is *not* in the 
language.  It's something peculiar to the compiler for ease of use. 

Sather designers recognize the eventual need for some very large scale
organizing mechanism but don't think that the common notion of
'modules' are good enough.   There were a flurry of proposals a little
over a year ago on the internal mailing list, but no satisfactory agreement,
except that other issues are more immediately pressing. 

Personally I don't feel that a "boxes in boxes" traditional hierarchical
approach is the right concept.  

We're on the lookout for something simple, clear, powerful and brilliant. 


cheers
matt

http://www.icsi.berkeley.edu/~sather