going from OOD to OOP
in [OOP]
|
Prev: pcnetsecurity@gmail.comAssistência Técnica manutenção de computadores informatica Vitória-es 13282
Next: Call for Papers: FCS'10 (The 2010 International Conference on Foundations of Computer Science), USA, July 2010
From: Alexander on 15 Feb 2010 10:40 Hi all, I've got a few really novice questions (actually I'm quite confused): - does implementation exist at the OOD level or only at the OOP level? (I think it only exists at the OOP level) - does MI exist at the OOD level? (I think it does) - if MI can exist at the OOD level, can such a design be trivially translated to an OOP language that only supports multiple subtyping inheritance? (like Java or Objective-C if I understand these correctly) (I think any OOD can be trivially translated even to an 'ugly' hybrid language like Java using only Java interfaces --hence only subtyping inheritance-- and delegation). The source of my confusion comes from the fact that I'm always trying to think "abstractions" and that, to me, "pieces of code" and "code reuse" are really just an implementation detail. Is a subtype hierarchy inheritance or not? Most people consider that Java and Objective-C do not support MI because they do not support multiple subtype+subclass inheritance but still they do both support multiple subtype inheritance and to me coupled with delegation this is really MI. Any clarification on that subject would be most welcome, Alexander
From: S Perryman on 16 Feb 2010 15:02 Nilone wrote: > To me, supporting subtyping means the compiler allows me to specify > behavioural subtyping and is able to guarantee it. No "compiler" can ever "guarantee it" . Because the problem in general is *UNDECIDABLE* . But of course, there is nothing to stop you : - using/defining a prog lang that provides the means to define correctness artifacts (pre/post/ invariant conditions, equivalences etc) - creating/integrating an env where said artifacts are given to an automated proof system, and the veracity of the artifacts are shown. A prog lang such as Eiffel integrated with a proof system such as Larch would be a good starting point. And would probably determine a lot of things correct/wrong with most typical software systems. Regards, Steven Perryman
From: Nilone on 16 Feb 2010 16:58 On Feb 16, 10:02 pm, S Perryman <a...(a)a.net> wrote: > Nilone wrote: > > To me, supporting subtyping means the compiler allows me to specify > > behavioural subtyping and is able to guarantee it. > > No "compiler" can ever "guarantee it" . > Because the problem in general is *UNDECIDABLE* . > > But of course, there is nothing to stop you : > > - using/defining a prog lang that provides the means to define > correctness artifacts (pre/post/ invariant conditions, equivalences etc) > > - creating/integrating an env where said artifacts are given to an > automated proof system, and the veracity of the artifacts are shown. > > A prog lang such as Eiffel integrated with a proof system such as Larch > would be a good starting point. And would probably determine a lot of > things correct/wrong with most typical software systems. > > Regards, > Steven Perryman You're right, behavioural equivalence is undecidable. However, what I want is a little simpler. C++ comes close with virtual inheritance, but it fails to transcend from the physical representation of data to logical abstractions. Forget equivalence and just look at whether the method has been implemented. If two types contain methods with the same name (and it isn't the exact same method, i.e. inherited from a shared parent) then those types conflict and can't be simultaneously inherited from. The derived type must end up with the union of its parents' attributes and methods. If one of the base types contain an abstract method and another a concrete method with the same signature, the concrete method automatically overrides the abstract one. I want this subtyping mechanism restricted to value types, i.e. copy on assignment and no possibility of obtaining a pointer or shared access to a variable of such a type, since variable subtyping is possible in a single-user environment. I want methods that read from such values to do so covariantly, and methods that modify such variables to do so contravariantly. Read-write access should be invariant. Finally, I don't want this instead of classes, I want it in addition to them. While I'm defining my ideal type system, let's remove implementation inheritance from classes, and add Third Manifesto-style relations instead of the usual mix of indexed and associative arrays. Do you think that is realizable, or am I missing anything?
From: Nilone on 16 Feb 2010 09:50 On Feb 15, 5:40 pm, Alexander <alexanderpaterso...(a)yahoo.fr> wrote: > Hi all, > > I've got a few really novice questions (actually I'm quite confused): I don't blame you. My experience with subtyping and subclassing in class-based languages ranks below quitting cigarettes. > > - does implementation exist at the OOD level or only at the OOP level? > (I think it only exists at the OOP level) I'm not sure what you mean. When you design a system, you design it to be implemented, don't you? Your design should be based on the semantics of your intended implementation framework. Implementation does exist on the design level, but is abstracted over, so it's something in your mind, not in the artifacts of the design. > > - does MI exist at the OOD level? (I think it does) > > - if MI can exist at the OOD level, can such a design be trivially > translated to an OOP language that only supports multiple subtyping > inheritance? (like Java or Objective-C if I understand these > correctly) Inheritance is a language mechanism that derives one class's attributes and/or code from another. It exists on the design level only as far as you're designing for a specific language or framework. Subtyping is a basic logical relationship. It exists on the design level if you classify your design artifacts hierarchically. Unfortunately, it may not exist as a mechanism in the language you're targeting, or may exist only partially. It may be possible to implement that relationship in your target language regardless of the language's support for it. I have yet to see a programming language in which subtyping is trivial to implement, whether single or multiple. One of the reasons for that is that subtyping is context-sensitive, and impossible to enforce on mutable shared objects or in a reflective environment. It should have been trivial to subtype structs via multiple inheritance, but here our language designers failed us. Java supports single implementation inheritance (extends) and multiple interface inheritance (implements). By default, its inheritance mechanism produces subtypes of the interfaces of classes, not of the implementation of classes, even in the case of extends, since it's still possible to override methods which will break any behavioural subtyping relationship. To get the compiler to enforce behavioural subtyping that is polymorphically substitutable for the parent type, you first have to make the base class immutable, mark all methods final, and avoid self- inspection via reflection. Alternatively, you can just implement a behavioural subtype by inheriting the interface and ensuring that the subclass responds exactly the same in every situation as the base class would (either via delegation or re-implementing the code), but in this case the compiler won't guarantee the relationship. > > (I think any OOD can be trivially translated even to an 'ugly' hybrid > language like Java using only Java interfaces --hence only subtyping > inheritance-- and delegation). To me, subtyping means if S <: T, then P(T) => P(S), where P(X) can refer to the result of executable code in X as well as externally visible attributes of X. > > The source of my confusion comes from the fact that I'm always trying > to think "abstractions" and that, to me, "pieces of code" and "code > reuse" are really just an implementation detail. > > Is a subtype hierarchy inheritance or not? No, they're not the same thing. > > Most people consider that Java and Objective-C do not support MI > because > they do not support multiple subtype+subclass inheritance but still > they > do both support multiple subtype inheritance and to me coupled with > delegation this is really MI. To me, supporting subtyping means the compiler allows me to specify behavioural subtyping and is able to guarantee it. I don't know of a working compiler which can do this. Of course, inheritance and delegation are powerful tools and much can be accomplished with them. In the end, all Turing-machine equivalent languages are able to achieve the same results. What I want is a language in which I can express myself effectively and efficiently, and I believe multiple behavioural subtyping would be a valuable tool in certain situations. > > Any clarification on that subject would be most welcome, > > Alexander I hope my thoughts on the matter contribute. I also welcome further clarification.
From: BGB / cr88192 on 22 Feb 2010 19:54
"Alexander" <alexanderpaterson39(a)yahoo.fr> wrote in message news:bd2e45c6-ba2b-48e6-a174-aa44050a02cc(a)o30g2000yqb.googlegroups.com... > Hi all, > > I've got a few really novice questions (actually I'm quite confused): > > - does implementation exist at the OOD level or only at the OOP level? > (I think it only exists at the OOP level) > IMO, this is ambiguous... > - does MI exist at the OOD level? (I think it does) > > - if MI can exist at the OOD level, can such a design be trivially > translated to an OOP language that only supports multiple subtyping > inheritance? (like Java or Objective-C if I understand these > correctly) > > (I think any OOD can be trivially translated even to an 'ugly' hybrid > language like Java using only Java interfaces --hence only subtyping > inheritance-- and delegation). > AFAIK, this is mixing interface with implementation... if one is designing something apart from a language, then MI vs SI, ... should not matter, since then one would not likely define an inheritence heirarchy in the first place (instead, one could state things in terms of conceptual relationships, rather than how they would be implemented in the language, then whether one uses MI, SI, or simply non-inheriting classes accessed via interfaces, or even raw C structs and exported API's, ... does not matter...). if one then does care to specify things like inheritence, specific APIs / behaviors, ... then this is naturally specific to "an" implementation language (there may be a little room, but more of the sort that the design could be faithfully implemented in C# or Java without modification, ...). if one then goes and specifies package/namespace/file/... organization, well then, one has generally taken out nearly all room for flexibility... > The source of my confusion comes from the fact that I'm always trying > to think "abstractions" and that, to me, "pieces of code" and "code > reuse" are really just an implementation detail. > for other reasons, I personally despise this notion of "just an implementation detail". often, this sort of wording is used by those who condescend the reality on which abstractions are based. an abstraction exists to gloss over the details of an implementation and to allow increased flexibility, rather than to allow one to remain ignorant of the matter (and, yes, there is a difference). the reality of the matter is primary, and all that one thinks of it, or however one formalizes it or describes it, is of secondary concern. it doesn't matter so much that the world is very often described in terms which are, FWIW, blatently incorrect (and if taken at face value could allow interpretations which are terribly wrong). these broken abstractions, however, work fairly well so long as one does not confuse them for the underlying reality being described. so, a programming language abstracts over the HW, but by no means does it trivialize it, and a design may abstract over the specifics of an implementation, but by no means does a design mitigate its implementation. > Is a subtype hierarchy inheritance or not? > not really... they are "related", but little is to say they are equivalent. consider for example a conceptual numeric hierarchy: vector space hamilton space complex space real numbers rational numbers integers natural numbers evens, odds ... fractional numbers ... irrational numbers complex numbers quaternions octonions ... euclidean space ... now, assuming one were to implement a numeric tower (value representations, operations, ...). would they likely choose inheritence to represent this tower: probably not. in fact, it would likely lead to a very poor implementation if they were to use inheritence. actually, a much better strategy would be to simply invert the entire tree, and choose a different root point, such as integers, ... or to not bother with trying to shoehorn the numeric tower into an inheritence hierarchy. actually, it is at this point where I personally feel existing "OOP" practice has often gotten things wrong, as these sorts of complicated trees tend to be annoyingly common, with people naively thinking that a big inheritence tree of this sort is itself simply the correct way to implement these sort or taxonomies (rather than considering that, instead, a better solution may have a multiple/many roots, or even be organized very differently from the conceptual set of relationships). > Most people consider that Java and Objective-C do not support MI > because > they do not support multiple subtype+subclass inheritance but still > they > do both support multiple subtype inheritance and to me coupled with > delegation this is really MI. > it is not clear what is meant by this... > Any clarification on that subject would be most welcome, > > Alexander |