Real OO (was Choice of OO primitives in Ada95) 
Author Message
 Real OO (was Choice of OO primitives in Ada95)


[...]

: >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.
: Are you sure these are the best sub-goals ? That there are no other ones ?
: And that in  stating the goals, you were not influenced by the conclusion
: you wanted to draw ? But let's go with it for the moment.

The sub-goals are intended to reflect the philosophy of OO. The fact that OO
principles are implied by the goals is quite intentional and appropriate. Others
may be identified, but the ones stated have a direct bearing from an OO perspective.
What matters is whether the sub-goals stand on their own and I think they do.

What is the philosophy of OO? Perhaps:

"To incrementally model the application domain using unique, clearly defined
abstractions which are reused through sharing and extension".

In other words, analyse the application domain for common behaviour and classify
that behaviour. Uniquely encapsulate a class of behaviour and only that behaviour
into a single abstraction and use that abstraction wherever such behaviour is
required.

This implies that behaviour should be modelled once and once only and the behaviour
should be reused wherever needed. It also means that such behaviour should be
distinct and not co-encapsulated with other abstractions or co-encapsulated with
extraneous data (both of which are allowed by Ada). The encapsulation contains
the abstraction, the whole abstraction and nothing but the abstraction.

Many of what are promoted as closely related abstractions (marriages and people),
(lists and cursors) are really distinct abstractions which, if modelled correctly
should be separated into separate encapsulations. Co-encapsulating them is an
indication that the modelling process hasn't been taken far enough. It is not
complete until each distinct abstraction has been identified and encapsulated in
it's own distinct module.

This is not a matter of personal preference; it is a matter of maintaining the
conceptual integrity of the model of the problem domain and is supported by
pragmatic arguments based on the importance of reuse as advanced below.

Reuse is the driving force behind the rationale.

Reuse is promoted by clearly defined abstractions. The clearer an abstraction is
to the developer, the more reusable it is. One aspect of being clearly defined is
being VISUALLY distinct. You shouldn't have to search through a spec to find what
constitutes the abstraction and what doesn't. It should be self evident. If an
abstraction is VISUALLY distinct, you don't have to waste mental energy searching
for it's boundaries to differentiate it from other abstractions and unrelated
information. Your mental energy may be devoted entirely into comprehending the
abstraction itself. The clearer a developer's understanding of an abstraction, the
more reliable their code will be and the easier they will be able to reuse the
abstraction. Co-encapsulation obfuscates abstractions so has a counter effect.

Distinctly encapsulated abstractions also promote reuse (by inheritance) because a
developer is able to reuse exactly that abstraction - nothing more and nothing less.
Co-encapsulation forces reuse of whatever else happens to be defined in the module
whether it is required in the derived abstraction or not.

Reuse is also promoted by the use of assertions. This is because if abstractions
are correct, then that correctness is propagated throughout the software through
reuse. A corollary is that erroneous abstractions propagate errors throughout
software through reuse. This fact means that it is IMPERATIVE that the developer
has a high level of assurance that the reused abstractions are error-free. So,
a mechanism which promotes the development of such reliable abstractions is
essential to the OO model. Assertions are that mechanism. They attempt, where
possible to ensure that when an object is updated, it is still valid afterwards.

Reuse is also promoted by GC. How? Because it liberates the developer from the
drudgery of having to manage the objects in the system and allows him to focus
attention where it ought to be - you guessed it - on the abstractions. In any
non-trivial software, objects are shared here there and everywhere and it becomes
an unnecessary burden for the developer to have to manage their deallocation.
The beauty of GCs is that you don't have to worry about it. You can focus your
mental energy on modelling the problem domain and your abstractions are not
cluttered with extraneous information (deallocation commands).

Granted GC is problematic at present for Hard Real-Time Systems because software
is typically executed on a single processor. I envisage this hinderance being
removed when Shared Memory Processing becomes mainstream (as it no doubt will).
Such architectures will permit the application per se to execute on one processor
while the GC is churning away on another deallocating dead objects and compacting
live objects. But that is another thread...
In the meantime, GC is not viable for HRTS.

: >In order to acheive those goals optimally, an OO language should offer:
: >
: >1) encapsulated abstractions (classes)
: OK, but of course you mean that there must be a clear separation, at
: language level, between specification and implementation

No. This is not necessary and, IMO, even undesirable - tools can be used to
extract interface details. Repeating the specification in the implementation
(as in Ada) means you have to maintain the specification in two places. This
is contrary to the OO philosophy of defining something in one place only.
(Eiffel programs consist only of implementations and specifications (short form
and short flat form) are derived using tools).

: >2) inheritance/polymorphism of those abstractions
: How  can you deduce this from b) ? Inheritance is definitely one possible
: way, but you are claiming here it is the only one. I think building an
: abstraction by putting together standardized, appropriate building blocks
: and lower level abstractions is another way of achieving b) that does not
: require inheritance.
: Both approaches have benefits and drawbacks. I'm just irritated each time I
: see that because inheritance is one way of solving a problem, people think
: it is the only one.

Sorry if this was misleading. The intention was to focus on the OO aspects. I
acknowledge that using instances of abstractions (withing Ada packages or specifying
Eiffel attributes) is no less important a form of reuse than inheritance. Few would
dispute that.

: >3) control over the state of those abstractions (assertions).
: I think a typing system that does not allow  adding a length to a velocity
: is much more important for c) than assertions that are nothing more that a
: user definable function call.

You can do that in a strongly typed OO language (eg. Eiffel):

expanded class LENGTH
  inherit INTEGER
end

expanded class VELOCITY
  inherit INTEGER
end

Instances of LENGTH may not be used where VELOCITY is required and vice versa.

User definable function calls may be used in assertions, but that is not what they
are. They are executable conditions which, if not satisfied, result in an exception
being raised. When used in preconditions of operations, they guarantee the caller
satisfies the 'contract' placed on parameters (eg. non-zero divisor). When used as
postconditions of operations, they guarantee that what the object has acheived what
it has contracted to do. When used in invariants, they guarantee that after every
operation on the object, the object remains in a valid state. There are others.

: >
: >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?).
:
: 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. And as for separating specs and implementations, Ada
: is the only language that does it nicely, without giving up safety.

Initialisation of distinct instances is effected by executing a nominated operation
when the instance is instantiated eg.

!!a.make(...)

Since once attributes are shared instances, it would be nonsensical for instances
of the enclosing class to explicitly instantiate them in the same manner as for
distinct instances (they can't all instantiate it!). So, the initialisation block
is defined with the attribute itself and executed once when the object is
instantiated (which occurs when it is first referenced). Granted it would be nicer
to have a consistent mechanism for initialisation of distinct and shared instances
and rest assured the topic is periodically discussed in comp.lang.eiffel.

I don't see what safety is gained by separating interfaces from implementations.

: >
: >2) The linchpin of OO - any language claiming to be OO offers this.
: Including Ada 95, although I still think it has been overadvocated.
: >
: >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:
: > [...]
: It was considered in the early stages of Ada ...

read more »



Sun, 16 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)
Here is the original post for this thread (originally posted only in comp.lang.ada).
Subsequent addtitions as marked.
-------------------------------------------------------------------------
[Ada-specific stuff deleted]

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).
-------------------------------------------------------------------------
Add:
4) garbage collection
5) concurrency
-------------------------------------------------------------------------

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.
-------------------------------------------------------------------------
Add:
4) Because it frees the developer from drudgery of memory management
   allowing them to focus on abstractions.

5) The real world is concurrent!
-------------------------------------------------------------------------

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

While Eiffel is strong in the OO stakes (it satisfies 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 is a concern to you,
I suggest taking a look at Eiffel.

Don.



Sun, 16 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

Quote:

>While Eiffel is strong in the OO stakes (it satisfies all 3), it is weak
>(unfortunately) in the RT arena. These weaknesses are:
>a) poor low level facilities (bit fiddling)

How does one do bit twiddling and string manipulation in Eiffel?
Thanks,

Quote:
>Don.



Mon, 17 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)


:
:    >In order to acheive those goals optimally, an OO language should offer:
:    >
:    >1) encapsulated abstractions (classes)
:    OK, but of course you mean that there must be a clear separation, at
:    language level, between specification and implementation
:
: <snip>
:
:    >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?).
:    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. And as for separating specs and implementations, Ada
:    is the only language that does it nicely, without giving up safety.
:
:
: Uhhh... since when has "encapsulated abstractions" been defined as limited
: to classes?  "Classes" are a way to encapsulate all the operations that are
: associated with an object type.  "Interfaces" (where classes are really a
: more restricted form of these) encapsulate all the operations that are
: associated with the types visible to that specification -- there isn't
: the single type restriction.

Classes can contain data and/or operations. So, they do not only encapsulate
operations. They may:

i)   contain data only (analogous to record types)
ii)  contain operations only
iii) contain both data and operations.

Interfaces are just a statement of what is exported from the encapsulation.
Sure you can co-encapsulate if you like but, as I've indicated elsewhere, it is
more advantageous from a reuse perspective to uni-encapsulate abstactions
(distinctly encapsulate).

: I also obviously do not agree with the explanation for (1), but I also
: have to disagree with the statement that Ada is the only language that
: separates specifications from their implementations, in a nice and
: safe manner.  Modula-3 has a similar interface/implementation
: separation, which is just as nice and equally as safe.  (It actually
: resolves other safety issues not related to pure OO programming, but
: that isn't what is being discussed here)

As I've indicated previously, there is no need to (and it is actually desirable
not to) separate interface and implementation.

: I think Ada has a powerful encapsulation system, but it is not the
: only language with one.

Eiffel's encapsulation mechanism is more powerful (than Ada's) due to the fact
that it better facilitates reuse.

: -Spencer

Don.



Tue, 18 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

[...]

: Yes, Don says a lot of things.  He also says the following in
: c.l.e:
:  
: <<<
: For anyone interested, I've just stirred up the Ada nest with a posting
: titled 'Real OO'.
:  
: I didn't cross post it to here, for fear of boring you all with endless
: follow-ups.
:  
: Regards,
: Don.
: >>>
:
: Basically, he's just trolling.  So, it is best to not waste time
: replying to anything he posts.

By all accounts, I must be the most prolific troller in history wrt follow-ups :-).

: /Jon

Don.



Tue, 18 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

writes:

|> Classes can contain data and/or operations. So, they do not only encapsulate
|> operations. They may:
|>
|> i)   contain data only (analogous to record types)
|> ii)  contain operations only
|> iii) contain both data and operations.

In other words, you can use classes as packages, thus making the only
issue in this debate the choice of keywords!

|> Interfaces are just a statement of what is exported from the encapsulation.
|> Sure you can co-encapsulate if you like but, as I've indicated elsewhere, it is
|> more advantageous from a reuse perspective to uni-encapsulate abstactions
|> (distinctly encapsulate).

That's easy to say, but what constitutes an abstraction?  I believe that
abstractions involving multiple types are commmonplace, so that it is too
constraining to presume that an abstraction consists of a single type
plus its operations.

--



Tue, 18 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

Quote:

> 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".

I agree that the above is a noble pursuit. One must keep in mind, though, that
this has been a goal of most programming languages, and is not unique to OO.
Many Ada advocates would say that Ada is ahead of the pack in this regard.
Certainly Ada was designed specifically to meet that goal.

Once the goal is met, who cares how you got there? I for one am not going to lose
sleep if Ada95 is not "real" OO.

Quote:
> 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.

Again, I suggest the Ada advocates would claim Ada meets these goals. And while
I agree that OO does go a long way to meeting these goals, there is nothing to
suggest that there is no other way of getting there.

Quote:
> 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).
> -------------------------------------------------------------------------
> Add:
> 4) garbage collection
> 5) concurrency
> -------------------------------------------------------------------------

I guess I see two different issues here:

1) Is OO the *best* way to attain software nirvana and improved quality of life?

2) Is Ada real OO?

In my mind they are two separate questions, *unless* it is shown that OO is
"the way, the truth, and the life". One might argue that C++ is more OO than
Ada95, yet be less useful for achieving the goal.

Matthew M. Lih
Software Lead, SAIN Project
TRW Enterprise Solutions



Tue, 18 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

Quote:

>> The purpose of OO, as I see it is this:
>> "To enable the cost-effective development of correct, reliable
>> and maintainable software".

>I agree that the above is a noble pursuit. One must keep in mind, though, that
>this has been a goal of most programming languages, and is not unique to OO.

This is probably the most sensible point mentioned on this thread.
Unfortunately "Object-Orientation" is still a buzzword many many
years after it was first introduced.

Quote:
>Many Ada advocates would say that Ada is ahead of the pack in this regard.
>Certainly Ada was designed specifically to meet that goal.

>Once the goal is met, who cares how you got there? I for one am not going to lose
>sleep if Ada95 is not "real" OO.

Who coined the term "real" OO?  The famous Computing Surveys paper
of 1985 by Cardelli et al which basically *decreed* that
object-orientation required inheritance and dynamic
polymorphism in addition to ADTs, encapsulation, etc. etc. and
that if you didn't have inheritance and dynamic polymorphism but
only ADTs then you were only object-*based* etc. etc. comes to
mind.

[snips]

Quote:
>I guess I see two different issues here:

>1) Is OO the *best* way to attain software nirvana and improved quality of life?

>2) Is Ada real OO?

>In my mind they are two separate questions, *unless* it is shown that OO is
>"the way, the truth, and the life". One might argue that C++ is more OO than
>Ada95, yet be less useful for achieving the goal.

Which is a good reason why arguing which language is more OO than
another, or whether a language supports "real" OO is, as you say,
a different question entirely than whether the language is an
appropriate tool for constructing quality software.

Ray Toal



Thu, 20 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

| Tony says
|
| "Oh please, not again.  GC is often *required* in order to meet
| hard real-time constraints:  Name a heap-manager that doesn't
| have an exponential worst-case."
|

The subject thread was started as an obvious troll, which has
succeeded in getting Ada-ists going again (it doesn't take much);
remove comp.lang.eiffel from distribution of this thread.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

CEC Services, 2080 Kipling St, Lakewood, CO  80215-1502   USA
Voice: 303.231.9437;  Facsimile: .231.9438;  Data:  .231.9434  
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~



Fri, 21 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)


writes:

|> Remove comp.lang eiffel from distribution of this thread.

No.

--



Fri, 21 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)



Quote:
| writes:

|
| |> Remove comp.lang eiffel from distribution of this thread.
|
| No.
|
| --

Norman, maybe you don't understand, but your thread has nothing to do
with Eiffel (or IBM for that matter).  Stop being a big (blue) baby.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

CEC Services, 2080 Kipling St, Lakewood, CO  80215-1502   USA
Voice: 303.231.9437;  Facsimile: .231.9438;  Data:  .231.9434  
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~



Fri, 21 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)


|
| |>                              Name a heap-manager that doesn't
| |> have an exponential worst-case.
|
| Exponential time to do what, and exponential with respect to what?
| I know of no allocation algorithm that would require worse than an O(n)
| traversal of the free list.  Deallocation is O(1) with boundary tags,
| O(log n) for buddy allocation.  Compaction can be done naively in O(n)
| time by dividing memory into an "old" area and a "new" area.  What do you
| have in mind?
|
| --

This has nothing to do with comp.lang.eiffel.  

Remove this thread from distribution there.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

CEC Services, 2080 Kipling St, Lakewood, CO  80215-1502   USA
Voice: 303.231.9437;  Facsimile: .231.9438;  Data:  .231.9434  
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~



Fri, 21 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)

Quote:

> As I've indicated previously, there is no need to (and it is actually desirable
> not to) separate interface and implementation.

For some insane reason I thought about this Ada vs. Eiffel stuff over
the weekend (well, I just installed both GNAT and Eiffel) and I actually
came to the conclusion that it is actually *desirable* to separate
interface and implementation. Once the system has been architected the
interface can be protected in such a way so that one has read-only
access to it (e.g., place it in a separate file), no matter what becomes
of the implementation. In Eiffel, as I understand it, one can *extract*
the interface, but because it is inseparable from the implementation,
there is no way to prevent anyone who alters the implementation from also
altering the specification (read interface: sorry, my Ada reflexes!)

I've seen the phrase "programming by contract" associated with Eiffel.
I don't know what it means in that context, but in my mind separating
specification and implementation is a very strong approach to "programming
by contract", in the sense of "the implementation had better adhere
to the contract (specification), and if you want to change the contract,
you better talk to someone who's can ok the change".

An analogy: in Ada, one gives the client (designer) gives the
contractor (implementor) a copy of the contract, keeping the original.
In Eiffel, one gives the contractor the original of the contract, and
must trust the contractor not to alter the contract.

Disclaimer: I am just starting with Eiffel, so constructive correction is
appreciated.

Matthew M. Lih
Software Lead, SAIN Project
TRW Enterprise Solutions



Fri, 21 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)



[my incorrect example of chained classes deleted]

: >Each abstraction is related to the previous one but isn't necessarily related
: >to any other. As I understand it, the language rules dictate that each of these
: >abstractions must be in the same package.
:
: No, they don't have to be in the same package (and as you say, probably
: should not be).  Could you explain what you mean -- why do you think
: that all of the above types have to be in the same package?
: (By the way, the above code is illegal, by 3.9.2(12).)

I thought on the basis of RM 3.2.3(6):

"The primitive subprograms of a specific type are defined as follows:
(...)
For a specific type declared immediately within a package specification, any
subprograms ... that are explicitly declared immediately within the same package specification and that operate on that type".

that an operation could be an inheritable (primitive) operation of more than one
inheritable (tagged) abstraction. RM 3.9.2(12), as you point out, means that an
operation can only be a primitive operation of one tagged type. Thanks for the correction.

What this implies, however, is that even though parameters of non-inheritable
(non-primitive) operations are symmetric with respect to each other, this symmetry
is lost when one or more tagged types are used. In the context of inheritance,
dispatching operations DO BELONG to a SPECIFIC abstraction and the operands are NOT
SYMMETRIC with repect to one another. (They not only DO belong to a specific abstraction, but MUST belong to a specific abstraction for the purposes of polymorphism).

RM 3.9.2(12) means that with:
  type PERSON is tagged ...
  type MARRIAGE is tagged ...

you cannot have:
  procedure Wed (
    Groom : PERSON;
    Bride : PERSON;
    M     : out MARRIAGE);

in which case, Wed would be inheritable by descendants of both PERSON and MARRIAGE
because they are both tagged. You must remove the primitive status from one of the
operand types the eg.

  procedure Wed (
    Groom : PERSON;
    Bride : PERSON;
    M     : out MARRIAGE'Class);

In the context of inheritance, operands are intrinsically ASYMMETRICAL, NOT
SYMMETRICAL. In fact, the asymmetry of operands actually favours distinct
encapsulation rather than co-encapsulation because the operation belongs (in the
sense of being inheritable) to a single tagged type.

With respect to closely related abstractions, the example of a list and it's cursor
has been suggested as two abstractions that are so closely related, they should
be co-encapsulated. I suspect that when two abstractions are closely related like
this, it's usually a big hint that one should inherit from the other. In this
case, I think the LIST class should inherit from a LINEAR_CURSOR class. The
LINEAR_CURSOR class might be an abstract class with it's operations implemented
in the LIST class.

Sorry for not responding earlier.

[...]

: - Bob

Don.



Sat, 22 Aug 1998 03:00:00 GMT  
 Real OO (was Choice of OO primitives in Ada95)


:writes:
:
:|> Classes can contain data and/or operations. So, they do not only encapsulate
:|> operations. They may:
:|>
:|> i)   contain data only (analogous to record types)
:|> ii)  contain operations only
:|> iii) contain both data and operations.
:
:In other words, you can use classes as packages, thus making the only
:issue in this debate the choice of keywords!

No. It's much more than that.

:|> Interfaces are just a statement of what is exported from the encapsulation.
:|> Sure you can co-encapsulate if you like but, as I've indicated elsewhere, it is
:|> more advantageous from a reuse perspective to uni-encapsulate abstactions
:|> (distinctly encapsulate).
:
:That's easy to say, but what constitutes an abstraction?  I believe that
:abstractions involving multiple types are commmonplace, so that it is too
:constraining to presume that an abstraction consists of a single type
:plus its operations.

I think such abstractions would typically inherit those types (classes) in the
un-encapsulated scheme of things. They appear to be part of the higher level
abstraction because they ARE part of it (they are inherited by it).

:--

Don.



Sat, 22 Aug 1998 03:00:00 GMT  
 
 [ 100 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

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

2. Choice of OO primitives in Ada95

3. SENIOR OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

4. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

5. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

6. OO SOFTWARE DEVELOPER WITH OO SAVVY - TORONTO

7. Use of O.O. metrics to estimate the effert and cost of O.O. projects

8. Pure OO-What differentiates a true OO from object-based systems

9. Wanted: Non-trivial OO Ada95 Open Source programs on the web

10. OO Samples in Ada95...

11. Talk on Ada95 and OO Programming (San Diego)

12. on OO differnces between Ada95 and C++

 

 
Powered by phpBB® Forum Software