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

[mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew B. Kennel)]

Robert A Duff (bobduff@world.std.com) wrote:

: Encapsulation isn't some sort of Goodness, such that the more you have
: of it, the better.  No, you want to encapsulate things at the "right"
: level of granularity for the problem at hand.

I definitely agree with this. 


: An example is a List type, plus a List_Cursor type.  The List_Cursor
: points at a certain place in the list, and has operations for moving
: forward and/or backward and so forth.  These operations cannot be
: written without visibility on implementation details of *both* types.
: So if class=module, you have to *export* a lot of those implemenation
: details from one of them, so the other one can do what it needs to do.
: Putting them both in the same module, however, actually gives you
: *better* encapsulation, because fewer (and higher-level) operations get
: exported.

Of course, Eiffel has selective export, where individual features or sets
of features can be mutually exported and imported.   

Ada gives this set a name.  Better?  Perhaps. 

Eiffel can express notions of "who gets to see what" which are not easily
compatible with strictly hierarchical packages.   (Consider three
classes, A B and C with A sharing some routines with B and some with C, but
B and C sharing nothing. )

: Last time I looked at
Eiffel, the standard library classes put the : cursor movement stuff inside
the list.  That seems like a poor design, : since you can only be looping
through a given list once, at any given : time.  It seems to me that you
badly want the List_Cursor type to be : separate from the List type,
although they *are* part of the same : "module".

I might agree, but there's always the question of efficiency.  Most of the
time you're looping through one list once, needing to allocate extra
objects may be expensive.

What I really want, of course, is Sather's iterators which totally solves
the problem.  :-) 

: >While Eiffel is strong in the OO stakes (it satifies all 3), 

: I agree that Eiffel is superior to Ada with respect to your number 3) --
: that is, the assertion stuff.  Ada does have *some* support for
: assertions.  For example, if I say, "type T is range 1..10;", then
: there's an invariant on T -- all objects of type T have to be in the
: range 1 to 10.  This is pretty weak, compared to Eiffel, though.

: I think it's silly to call that part of OO, though.  It's a completely
: orthogonal issue.  Assertions would be useful in a non-OO language, too.

I wouldn't call it completely orthogonal.  A major point of polymorphic
object oriented programming, and specificially "design by contract" is
validating "who is substitutable for whom here?".  Eiffel expresses this
notion very directly in the combined type AND assertion system, as
descendents must be compatible both in type and assertion set with their
ancestors. 

I'm not a master of Ada, but it seems from reading Ada programs that
this information is not quite as readily obvious. 

: Meyer also said that garbage collection is a fundamental part of OO.
: Nonsense.  GC existed before OO, and it's not necessary in order to
: support the real fundamentals of OO, such as polymorphism.

: Why not just say that GC is a Good Thing, or assertions are a Good
: Thing, or Eiffel's assertions are better than Ada's assertions, or C++
: sucks because it makes it hard to implement GC?  It's silly to use the
: term "OO" as a synonym for "the set of all Good Things".

No argument.  I wait for the day whan "object orientation" is as much
an obvious (and uninteresting) prerequisite as "uses Unicode character set
in parsing". 

: >I think these will all be addressed in time but if none are a concern to you,
: >I suggest taking a look at Eiffel.

: Indeed.  Even if they *are* a concern, it's still instructive to learn
: Eiffel, and to read Meyer's classic book on OOP.  Programming by
: contract is a useful concept in any language.

: - Bob