Re: Extending protected types in 9X.

[asuvax!ennews!koehnema@gatech.edu (Harry Koehnemann)]

In article <1993Aug18.191808.24786@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David
 Weller) writes:

>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
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 9x semantics it is, isn't it?  An entire operation is exclusive.
Put a P() in front and a V() at the end (OK, the readers/writers issue
might add some complexity, but it's a solved problem).  After reading
Tartan's implementor report on Protected Records, I don't see the
difficulty you're implying.  It doesn't look that bad.  Maybe
they missed something :-).

Since you have much more experience in this domain, I will take
your word that it is more complex than I make it sound.  I'd be
interested in any references you have on the subject.

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

This may be a rub, but I'm not sure I understand what you are saying.
What is a "varied hierarchy of concurrency controls"?  And where are
they in 9X?


>>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?

In Eiffel, if I need to be persistent, I become persistent simply
by inheriting that property - regardles of my other properties.
Interactions are very regular and there are no "you can't protect a
tagged type" rules.  Further, they don't need to add a new construct
to the core language just to support persistent data, as Ada does
for each language feature.

Does this apply to concurrency?  I'll beat you to the punch and
admit that Eiffel does not have concurrency last I looked (it's been
a few years).  However, what precludes a "protected class" that
simply tells the compiler to protect the operations in the
interface?  Unless I'm missing something, we have P and V again.


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

Well yes and no.  Extensions obviously give us dynamic dispatching
and let us call Ada OO - one goal of Ada9X.  Do they get in our way
with additional language capabilities?  Ada adds a unique construct
for each feature we desire.  And, those features don't play well
with one another (extending protected types).

Inheritance based languages don't have that problem.  In fact, they
can even *remove* constructs from the core language (arrays in Eiffel).
I can also combine these features through inheritance (inherit from
Persistent and Array to form Database).  I don't know how this
combining of features works in Ada9X, if at all.  Ada puts each feature
into it's own construct - constructs that won't talk to one another.
I thought I could get my combining goal by "nesting "constructs.  It
was a premature thought, and probably wrong.

I contend there is a fundamental difference between type extensions
and classes and no one has yet determined the impact on a
programming language.  Classes appear to revolve around inheritance,
while Extensions are driven by type and type compatibility- but, hey,
so is Ada.  I think the jury's still out on extensions.

--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department