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: 103376,2ea02452876a15e1
X-Google-Attributes: gid103376,public
From: donh@syd.csa.com.au (Don Harrison)
Subject: Real OO (was Choice of OO primitives in Ada95)
Date: 1996/02/22
Message-ID: <Dn5qGH.9xH@assip.csasyd.oz>#1/1
X-Deja-AN: 140552423
sender: news@assip.csasyd.oz
references: <JSA.96Feb20143818@organon.com>
organization: CSC Australia
reply-to: donh@syd.csa.com.au
newsgroups: comp.lang.ada
Date: 1996-02-22T00:00:00+00:00
List-Id: <comp.lang.ada>


To Norman Cohen:

Thanks for giving the example about Family Trees.
I've gained access to an RM and Rationale. I'll go and check whether my
understanding is correct. (I was asking for trouble debating an issue without
the reference material handy).

To Jon Anthony:

On the necessity or otherwise of "tagged" and "'Class", I acknowledge that with
hybrid OO model adopted in Ada 95, it may be appropriate to require these of
developers - I'll reserve judgement until I've re-read the RM and Rationale.

---------------------------------------------------------------------------------
The real issue to me is that the Ada 95 OO model falls short of what real object-
orientation is about. The purpose of OO, as I see it is this:

"To enable the cost-effective development of correct, reliable and maintainable
 software".

The sub-goals required to facilitate this are:

a) Allow decomposition of the software into intelligible modules each of which
   represents a clearly defined abstraction and has a clearly defined interface
   with other abstractions

b) Allow the construction, where possible, of abstractions using abstractions
   that are already defined, customising them as necessary rather than
   defining abstractions from sctrach.

c) Allow the valid state of an abstraction to be clearly defined and enforced.

In order to acheive those goals optimally, an OO language should offer:

1) encapsulated abstractions (classes)
2) inheritance/polymorphism of those abstractions
3) control over the state of those abstractions (assertions).

Taking each in turn (and not attempting to justify them),

1) Best provided by pure OO (eg. Eiffel, Smalltalk) followed by hybrid OO
   language with proper classes (extendable types mapped onto modules)
   eg. (C++, myriad others) followed by hybrid OO with non-encapsulated classes
   (eg. Ada, CLOS?).

2) The linchpin of OO - any language claiming to be OO offers this.

3) The only significant OO language I know of that offers this is Eiffel.
   Assertions are executable conditions which must be satisfied to guarantee
   that an abstraction has a valid state whenever it is updated. These include:

   i)   pre-conditions on operations that callers are required to satisfy
   ii)  invariant conditions that must always be true when the abstraction is updated
   iii) post-conditions on operations stating what the abstraction guarantees to
        have done when the operation has been executed.

   There are others.

Note that Ada only fully satisfies 2) and has a sub-optimal mechanism for 1).

While Eiffel is strong in the OO stakes (it satifies all 3), it is weak
(unfortunately) in the RT arena. These weaknesses are:

a) poor low level facilities (bit fiddling)
b) GC renders it an inappropriate tool for hard real-time systems (although the
   emergence of mainstream parallel architectures will permit this)
c) no concurrency (an elegant model currently being implemented - not yet part
   of the standard).

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

Don.