Re: multimethod + multiple inheritance

On Mon, 20 Mar 2006 11:00:56 +0100, Laurent Deniau wrote:

No. It is the ability to change the class (and the type) of an object at
runtime. It is usually supported by language with dynamic typing or
Prototype language both with dynamic dispatch and it can be simulated by
language with predicate dispatch. The only languages I am aware of which
support static type checking and dynamic multiple inheritance (but with
some constraints) are the gbeta and caesarJ languages, see the papers
"Safe dynamic multiple inheritance" and "A virtual class calculus" from
E. Ernst for more information.

I don't see use cases for changing the class. One could allow changing the
specific type. I.e. let you have a polymorphic object, which consists of
the type tag and the corresponding specific object. You could change the
tag and replace the specific object. The following is legal Ada:

X : T1; -- T1 is derived from T
Y : T1; -- T1 is derived from T
Z : T2; -- T2 is derived from T
Chameleon : T'Class := X;
begin
Chameleon := Y; -- This is OK
Chameleon := Z; -- Raises Constraint_Error

Ada does not allow changing type tags, but this is not a compile-time
constraint!

BTW, there are good arguments for not changing the type tags (stack memory
allocation issues.) Then with a really good ADT one could achieve the same
effect using safe referential types (handles.)

Anyway, I don't see how to avoid "diamond diagram" if not by shifting all
the burden to the programmer.

This is exactly my question except that I do not have examples (in this
context: SI + dynamic multimethod + dynamic inheritance) where MI is
required ;-)

IMO, there is no any. For mutating classes one should just use Any'Class.
Mutating types are not so obvious, but transparent handles could do the
job.

IMO, it is like multiple dispatch, one can
emulate it using SI, and have countless problems with implementing quite
idiotic patterns.

Yes but in this case, you have a problem solved by O(2N^P) methods
instead of O(N*P) multimethods, where N is the number of the classes
overriding the less specialized multimethod and P the number of
specializer of the multimethod. Looks like something hard to do by hand
with SI when N > 2 and P >= 2.

Geometrical explosion is not the only problem, IMO, unknown siblings seem
worse.

From a bird's perspective, either MI should have a feasible and efficient
implementation, or there must be something badly wrong with the whole
concept of inheritance, subtyping, subclassing etc. I don't believe in the
latter.

Implementing MI *is* feasible with good efficiency (both size and speed)
otherwise I would not ask my question ;-) But when you want to implement
MI as aggregation with nearly the efficiency of SI then you start to
touch the state of the art of MI implementation, specially when
implementing object construction and destruction, "virtual" method
invocation and C++ like dynamic_cast operator.

Ah, construction and destruction is complete rubbish in all languages I
know! (:-)) This is yet another unsolved problem: extensible polymorphic
methods.

In my view one cannot solve construction/destruction controversy without
separation classes and types. If you have it, then you can have distinct
class and type constructors. Class constructors could then take care of MI
components, and dispatch within the body.

I think that T != T'Class is the crux of types systems yet to come.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: multimethod + multiple inheritance
    ... Prototype language both with dynamic dispatch and it can be simulated by ... This is a Slate example about the multimethod dispatch with protypes, ... I still don't see how this could justify need in mutating types. ...
    (comp.object)
  • Re: multimethod + multiple inheritance
    ... It is usually supported by language with dynamic typing or Prototype language both with dynamic dispatch and it can be simulated by language with predicate dispatch. ... there are good arguments for not changing the type tags (stack memory ... This is a Slate example about the multimethod dispatch with protypes, something very close to what I do. ...
    (comp.object)
  • Re: Turkish "ki" and Basque "zein"
    ... borrowed such a construction, you will be even more surprised I assume to ... some postpositions postpositions can even be pre-posed if desired. ... they define what is unmarked for the language. ... imperatives in the first place, and so '*vo ja:' is always wrong. ...
    (sci.lang)
  • Re: identity...... Was: The wisdom of the object mentors
    ... And what about construction of int? ... I construct all objects in the same manner.....(like a C++ compiler ... in mid air...I need a language, some axioms and some rules of ...
    (comp.object)
  • Re: German participles
    ... long have worked at expliciting the exact conditioning of their ... Sprachgefuehl had been able to do so, every language would be entirely ... given that this kind of construction often feels too terse ... ohne eigenem Hund an etc. etc.... ...
    (sci.lang)