From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: mbk@caffeine.engr.utk.edu (Matt Kennel) Subject: Re: Real OO Date: 1996/04/12 Message-ID: <4km6em$f53@gaia.ns.utk.edu>#1/1 X-Deja-AN: 147160750 references: <4kbqun$iiv@watnews1.watson.ibm.com> followup-to: comp.lang.sather organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory reply-to: kennel@msr.epm.ornl.gov newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-12T00:00:00+00:00 List-Id: 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