From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 18 Aug 93 23:18:08 GMT
From: magnesium.club.cc.cmu.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd@uunet
.uu.net  (David Weller)
Subject: Re: Extending protected types in 9X.
Message-ID: <1993Aug18.191808.24786@sei.cmu.edu>
List-Id: <comp.lang.ada>

In article <1993Aug18.220747.1911@ennews.eas.asu.edu> koehnema@enuxsa.eas.asu.e
du (Harry Koehnemann) writes:
>In article <1993Aug17.072336.21830@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (Davi
d Weller) writes:
>>
>>The Reader's Digest version is:  No, protected types cannot be
>>extended.  Nor can tagged types become "protected".  While it
>>is true you may nest one kind of type within the record structure
>>of the other, you fail to acquire the implicit benefits of that
>>nested type.
>
>Bummer.  Inheritance of properties is a typical feature in OO
>languages.  If I want to be "protected", I'll inherit that property.

Not bloody likely.  Here's the problem: Inheriting "protection" (that
is, inheriting properties that ensure the instance will behave in
a concurrent environment) isn't as simple as adding a keyword (unless,
of course, you just want something like mutex applied to each
operation).  Concurrency control is _not_ a property, rather it
is some form of specification that dictates how each operation will
behave concurrently.  Further, such concurrency controls can't be
"sprinkled on" as you trudge along creating classes,
since you may want specific instances to behave differently.  Finally,
implementing a varied hierarchy of concurrency controls on top of
the usual dispatching algorithms is (IMHO) something akin to a
gordian knot made of kevlar.

>If I need to be extensible, I'll inherit the tagged (lovely name)
>property.  It is not enough for an OO language to inherit operations,
>we must be able to inherit all the properties of the thing we desire
>to become.
>

In comparison to other common "OO" languages, Ada 9X successfully
accomplishes this.  If you disagree, can you please elucidate?

>Does one even "inherit" an operation in 9X - instead, it appears we
>"gain type compatibility with" an operation.  I guess this comes
>from the type extension approach taken in Ada9X.  We must nest
>rather than inherit.
>

How's that again?  My "nesting" comment wasn't related to the current
9X type extension scheme.  I think the current scheme does the job 
just fine, certainly no worse than other languages.

>Let's see - type extensions instead of a class construct, objects
>are passive rather than active

Huh?  Your comments seem to imply that, in some other language,
objects are genuinely active.  I don't know of any mainstream
language (besides Ada) that provides such a feature in the language.

>, now we have the inability to
>inherit properties - even for capabilities defined within the
>language.  I don't know, but that OO label we're putting on 9X
>keeps getting weaker.  Oh well, the hierarchical libraries look
>pretty slick.

Please defend your comments.

-- 
type My_Disclaimer is new Standard.Disclaimer with record
	AJPO, SEI : Cognizance := Disavow_All_Knowledge;
end record;--)