Path: utzoo!attcan!uunet!mcsun!inria!seti!wally!jml From: jml@wally.altair.fr (Jean Marie Larcheveque) Newsgroups: comp.object Subject: Re: prototypes and degenerate cases Message-ID: <1625@seti.inria.fr> Date: 19 Sep 90 13:29:20 GMT References: <1990Sep13.235832.23454@Neon.Stanford.EDU> <1608@seti.inria.fr> Sender: news@seti.inria.fr Organization: Gip Altair/INRIA, France Lines: 36 I earlier suggested that the circle-to-ellipse mutation could be handled without using dynamic inheritance, with something like class ellipse { concrete_ellipse *state_holder; // ... } where concrete_ellipse is a superclass of circle. However, I made things rather confusing by further suggesting that concrete_ellipse should be a subclass of ellipse and leaving out the * in front of "state_holder", and Bruce Cohen rightly objected: >But then don't you have to add a set of delegation functions to ellipse so >an instance of it can pass on calls to it's instance of concrete_ellipse? Yes indeed! Since we are using composition instead of inheritance to forward the behavior, we have to make this explicit, so it is not so neat as in Self, as we program an ad hoc mechanism instead of using generic mechanisms. However, the fact remains that, whether we dynamically act on inheritance links or create ad hoc links to allow switching between 2 types of behavior, this possibility has to be specified before any object is created. In one case, creation of a mutable object involves creating both an identity-holder and a parent behavior-holder, while in the other, the class definition has to specify behavior delegation. My knowledge of Smalltalk is insufficient to tell whether become: leaves the object identifier unmodified; but if such is the case, it is by far the best solution, as it allows objects to change classes even when this was not anticipated at the time of their creation. -- Jean-Marie Larcheveque or