Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tekcrl!brucec From: brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) Newsgroups: comp.object Subject: Re: prototypes and degenerate cases Message-ID: Date: 17 Sep 90 18:13:37 GMT References: <1990Sep13.235832.23454@Neon.Stanford.EDU> <1990Sep16.083629.10936@tukki.jyu.fi> Sender: news@tekcrl.LABS.TEK.COM Organization: Tektronix Inc. Lines: 54 In-reply-to: sakkinen@tukki.jyu.fi's message of 16 Sep 90 08:36:29 GMT I don't have time just now to reply to Markku Sakkinen's posting in detail, but I did want to make a few comments about areas where I think we're not talking about quite the same things. The posting is quite clear on the problems of a class-based implementation for the problem I described: in general, inheriting objects may not remove behavior or state variables, they can only override them. This is just why I looked for another solution. I don't think that we're in as good agreement on the nature of the prototype-based solution: In article <1990Sep16.083629.10936@tukki.jyu.fi> sakkinen@tukki.jyu.fi (Markku Sakkinen) writes: I wrote: >>Suppose instead that the objects inherited from prototypes, and the mutator >>merely changed the appropriate parent pointers to (e.g.) remove a >>degenerate object's redundant slots and change it's behavior to the less >>costly method. [...] > > This reasoning seems to me to be incomplete. > If the programming technique (in a prototype-based language like Self) > is such that the parent objects (Shape, Ellipse, Circle, ...) contain > the methods and the instance objects only the data, then the _behaviour_ > can of course be changes by changing the parent pointer. > But that does not magically remove the now superfluous instance variables > from the object! If that is wanted, the object itself must somehow be > modified just as in the class-based case. No, the data slots are also inherited, and need not be inherited from the same object the behavior is inherited from. There is a good example of just what I wanted to do that explains how data representation can be used in Self, in the paper "Organizing Programs without Classes" by Ungar, Chambers, Chang, and Holze, in the Self papers. In section 2.4, "Beyond Representation Sharing", they show polygon and rectangle classes which have different data representations but share the appropriate common behavior. > > The main reason for having a Circle class at all was to have a compact > and effective representation for an important special case. > According to this suggestion, when a circle becomes a general ellipse, > there will be _both_ a circle object _and_ an ellipse object. > And when an ellipse becomes a circle, there are no storage savings; > at best, the parent objects can be defined so that creating a new > circle object (!) is not necessary. There may be both a circle and an ellipse prototype, but if the instances in use are modified in place, there only needs to be one instance of each object, which might behave like (and have the data representation of) a circle at one time, and an ellipse at another. -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077