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: 20 Aug 93 00:25:52 GMT From: asuvax!ennews!koehnema@gatech.edu (Harry Koehnemann) Subject: Re: Extending protected types in 9X. Message-ID: <1993Aug20.002552.22804@ennews.eas.asu.edu> List-Id: 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