multimethod + multiple inheritance
in [OOP]
|
From: Laurent Deniau on 5 Apr 2006 06:55 Dmitry A. Kazakov wrote: > On Tue, 04 Apr 2006 10:33:13 +0200, Laurent Deniau wrote: >>Dmitry A. Kazakov wrote: > OK, you can define values as non-polymorphic, but that would exclude > polymorphism. No, because polymorphism is related to types (dynamic or static), not values. For example, Haskell is strongly statically typed and support polymorphism while dealing only with immutable values (pure functionnal => referential transparency). > I assume that there is nothing but values and types of. If > the thing, on which dispatch happens, is not value, then either it does not > exist or it is something beyond the types system. It is a concret representation of the type system, neither a value nor a type. From the implementation point of view, it is of course a value, but nobody needs to know this aspect which may differ between implementation. For example, in my C Object System, it is a 26 bits unique ID from a LCG 26 bits and hopefully the user do not need to understand this. >>>In a language where any message can be sent to any >>>object, you would soon forget about that type. But it is still present. >> >>what is the type of obj in: >> >>id obj = [String newWith "a"]; // objective-C >>my obj = new_string("a"); // perl >>(setf obj (make-string 1 :initial-element "a")) // Lisp >>var obj = 'a'; // Javascript >>$obj = 'a'; // PHP >>obj = 'a' // Python > > > Its type is the class of copyable objects (ones having '='). How do you know that '=' means copy? var x = 'a'; var y = x; y = 'b'; What is the value of x? May be 'a', may be 'b, you can't say because it is related to the semantic of the language used. And the two possible semantics (I assume no operator overloading) are by-value (i.e. x='a') and by-reference (i.e. x='b'). >>>Example 1: write a calculator dealing with things above. >> >>Not a problem. > > > Hmm, with C++ templates? Show me the code. Google a calculator written in C++ with templates and put whatever you want as the basic type for the calculator. >>>Example 2: provide all usual cross operations: matrix by scalar, submatrix >>>by matrix, all sorts of dimensioned matrices by differently dimensioned >>>matrices etc. >> >>Already done. Search for SL++, a library I wrote in 1998. It provides >>all what you says. It also handle dozen of matrix structures (Vector, >>Diagonal, [Row|Col]Major, [Upper|Lower]Triangular, Sparse, etc...), >>iterators, submatrix, implicit loops... > > > Can all these types be mixed? Yes of course, otherwise it wouldn't be very useful. And template specializations allow to *add* optimized algorithms for specific combinations. > Can I multiply a diagonal matrix to a > triangular one and get a triangular result? All that without MD? Yes and yes. MD has nothing to do with parametric polymorphism. > Anyway, why don't you use this as an example, rather than those ill sharks? > (:-)) Because my question takes place in a different context. Parametric polymorphism (templates) is a very powerful and efficient tool to mix together boxes, especially when types are used as decorators (e.g. SIUnits), but it is difficult to write correctly these boxes and even more difficult to extend them. And since everything is static (compile-time), they are not able to deal with dynamic designs (e.g. problem extended from 2 dim -> N dim at runtime). Dynamic typing + MD offer more flexibility for extensions and runtime, but combination of boxes requires often more work because of the geometrical explosion of variants. PP -> very good combination, hard to extend, very efficient MD -> very easy to extend, hard to combine, less efficient >>>Switching from one sort of polymorphism to another really changes >>>nothing. >> >>Oh yes it does! > > > But without considering any concrete case, we could say that if there were > a parametric solution of the problem, then it should be transformable into > a dynamically polymorphic one. B. Meyer wrote a paper (if I remember well "Genericity vs Inheritance" 1986) showing that parametric solution (genericity) can always be implemented in term of polymorphism (inheritance). But the cost of such design conversion can be huge because of the geometrical explosion of variants. This is probably why C++ template have a such success today. >>I don't know what you call "static polymorphism", but static binding >>doen't need table. But if you have subtyping, coercion and overloading >>(ad-hoc polymorphism), then the compiler may have some work to select >>the right method. It may be even more complex if you have parametric >>polymorphism and namespaces on top of these. > > > Yes. But how this reduces the number of variants? Because the compiler generates the variant automatically for you using some rules on subtyping, coercion and overloading of types. If you provide appropriate specialization, it will use it. > Some inconsistencies, not all of them. And the compiler should have some > additional information about the structure of the methods. What I miss in > all proposals is that additional information, like commutativity. But there is such proposal. There is some example where types are used to map the properties of algebra. One of the oldest one that I know is the book "Scientific and Engineering C++", by John J. Barton and Lee R. Nackman, Addison Wesley 1994. One of the most complete one that I know is Algebraic Concepts Represented in C++ at http://www.cs.chalmers.se/~schupp/old_projects/simpl/doc/AlgCpp.pdf a+, ld. |