Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: prototypes and degenerate cases Message-ID: Date: 13 Sep 90 13:09:23 GMT References: Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 72 Nntp-Posting-Host: odin In-reply-to: brucec@phoebus.phoebus.labs.tek.com's message of 11 Sep 90 21:14:57 GMT On 11 Sep 90 21:14:57 GMT, brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen) said: brucec> I've just been reading the Self papers, and it occurred to me brucec> that using prototypes for inheritance could solve a problem brucec> which has been annoying me for quite some time. Maybe some of brucec> you out there coould comment on the theory and/or practice of brucec> the idea. brucec> Consider an object-oriented graphic drawing system, in which brucec> there's a general shape object, a polygon object, a rectangle brucec> object, a circle object, and an ellipse object. One way you brucec> could arrange class inheritance for such objects is like this: [ ... describing the problem where an object's class semantics are a derivative of its parent's, but is implementation need not be ... ] This is the age old problem, which I never tire to describe, that you want to reuse interface, semantics, implementation separately. In your case you want to reuse the interface and semantics of Shape for Polygon, and again for Rectangle, but you don't want to reuse the implementation of Polygon for Rectangle. [ ... describing substituing an object implementation for another, either with an in-built become:, or with a manually implemented version ... ] Your two alternatives, incidentally, are exactly the same; when you reject become:, you propose an alternative that is equivalent to manually implementing become: itself. brucec> Suppose instead that the objects inherited from prototypes, and brucec> the mutator merely changed the appropriate parent pointers to brucec> (e.g.) remove a degenerate object's redundant slots and change brucec> it's behavior to the less costly method. Consider the ellipse brucec> being converted to a circle (warning: Self notation): brucec> Ellipse Circle: brucec> ------ ------- brucec> parent:-----------> traits circle parent:-------> traits ellipse brucec> focus1 -----------> 0@0 <------------ center brucec> focus2 -----------> 0@0 brucec> focus1: <- brucec> focus2: <- focus2: <- brucec> major radius -----> 1 <------------ radius brucec> minor radius -----> 1 brucec> major radius: <- brucec> minor radius: <- This is OK -- what you do is to redefine inheritance so that you inherit protocol but not implementation. This can be done in CLOS, as well. brucec> This seems significantly cleaner than becomes, and perhaps less brucec> work than the hand-crafted mutator in the class-based approach. brucec> Anyone have any comments? If done at run time it requires an interpreter or a runtime compiler, because you are changing dynamically the layout in memory of slots and the access algorithms to them. This may be available for Common Lisp and Self, but not for simpler languages. And it is not that different from become: really; it is an in-place version of become:, where you also twiddle the parent pointer. Bah. I think that become: is clean enough, can be implemented easily, and is more flexible. It merely requires runtime diaptching of methods, not runtime compilation. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk