Re: Real OO (was Choice of OO primitives in Ada95)

[jsa@organon.com (Jon S Anthony)]

In article <4git9e$cqi@stc06.ctd.ornl.gov> kennel@msr.epm.ornl.gov (Matt Kennel) writes:

> > Of course, I do not agree. For example, the presence of ONCE functions in
> > Eiffel is a kludge to overcome the absence of package initialization that
> > is nicely provided by Ada.
> 
> Um maaaaybe, but 'once functions' do what they do with no fuss and with
> very clear semantics, without having to define an "elaboration" notion for
> packages. 
> 
> I'm not sure that's a "kludge" compared to the complexity of package
> initialization in Ada. 

I would agree that "once functions" make sense in the Eiffel design
pattern and are not really a kludge.  Ada elaboration, of course, fits
its design pattern.  In this particular case, there really isn't much
difference between them in the effects that can be accomplished.  Ada
elaboration provides for a few more things but that is more due to the
fact that packages are not types.


> >  And as for separating specs and implementations, Ada
> > is the only language that does it nicely, without giving up safety.
> 
> This isn't true.

Correct, M3 (and M2) for example provide this as well.


> You write abstract classes in Eiffel/Sather/C++ which has the spec
> (including pre/post/invariant) and write an implementation class which
> supports it. 
> 
> What is the problem?

I don't know.  But it is not the same.  You still have the interface
of the so called "implementation" class which is inextricably hooked
to _its_ implementation.  The fact is that Meyer (for various reasons)
decided _against_ separation of interface and implementation.  So, if
you are going to argue about this, you should be arguing about whether
this choice was "a good idea" (and not pretending that it isn't true).


> No.  Meyer figured out, quite successfully IMHO, exactly the kinds of
> rules that you need to turn "assertions" from just 'check this predicate
> and bomb if false' into a powerful *human* protocol "programming by
> contract". 

Well, more or less.  To me the real important thing about Eiffel
assertions is that they "go in the right place".  For example, it
is up to the client (enforced via assertions) that the pre-conditions
of a "server" are satisfied.


> These special rules are exactly what you need so you CAN trust assertions,
> because it means that you can put in truly useful checks that don't barf
> because of stupidities like the above. 

Well, more or less.


> I think it *is* quite fair to say that Eiffel is more object-oriented---ok
> more oriented-around-objects than Ada 95: it's the idee' fixe for Eiffel. 

From the standpoint of the 'everything is an "object"'
fanat-ahhh-ideology this is clearly true.  Actually, it is even more
specific than this, viz, all the world's a class.  I'm not
particularly enamored of this point of view.  For one thing it is not
obvious what the statement even says, if for no other reason than the
fact the central concept is so ill defined as to be meaningless.  Of
course, this sort of fact has never bothered programmers before - and
probably never will.


> This doesn't prove 'prima facie' superiority, though I tend to like
> Eiffel better.  (I've never been convinced about kludges to handle the 
> 'multiple withing' problem).

Check.  As for the "withing" problem, well it is clearly an easy and
legitimate target.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com