Re: Ada OO Mechanism

[Robert Dewar <robert_dewar@my-deja.com>]

In article <7ircia$ued@drn.newsguy.com>,
  chris@nospam wrote:
> Today I saw a book on modula-3.
>
> I think Ada OO should have been designed as modula-3 OO is.
>
> So, here we have a language, which I thought was very similar
> to Ada, but used the familiar class like construct for the OO
> type.

> I have no idea why Ada did not do it the same way. I wonder if
> when Ada95 OO was designed, if modula-3 was around?

Yes, of course it was.

The thing to realize is that the design of Ada 95 is the way
it is not because someone didn't think of something, but on
the contrary because a lot of people thought a whole lot.

The key point in Ada is to provide orthogonal features that
can be used for many purposes. Some of these features are
modularity, information hiding, procedural abstraction, type
extension, inheritance and dynamic dispatching.

Yes, it is possible (and convenient) to use these for various
object oriented paradigms, but they are more general than this,
and are designed to be convenient to use in more general
circumstances.

For instance, take the example I mentioned, if you define an
algebra of operations on elements with operations such as
addition, then it makes good sense to use the notions of tagged
types, extensible types, inheritance and dynamic dispatching
to provide a definition that can be extended, e.g. a more
complex algebra can be developed which adds a multiplication
operation.

Now all this is expressible very nicely in Ada (I leave it as
an easy, though not trivial, excercise to write the code), but
it really does not make any sense to think of addition as a
method which sends messages to the elements thought of as
objects. This is a forced viewpoint that might have to be used
in other languages, but definition will not be helpful in
modeling an algebra, where the notion is a functional one,
rather than a procedural one with objects.

Note that in this case, the elements have no state, they are
just values.

Indeed you can take an entirely applicative view of this
construction in Ada without the slighest sense of procedural
thinking. Given that the notion of object is all about state
and sending messages that interact with this state, objects
are really quite inappropriate for this particular application.

In particular, this example cannot be programmed nearly as
neatly in Modula-3.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.