Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.object Subject: Re: Void references Message-ID: <1990Nov15.222835.24706@Think.COM> Date: 15 Nov 90 22:28:35 GMT References: <454@eiffel.UUCP> <1990Nov15.011702.25087@Neon.Stanford.EDU> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 45 In article <1990Nov15.011702.25087@Neon.Stanford.EDU> craig@Neon.Stanford.EDU (Craig D. Chambers) writes: > In most existing class-based languages, it is not >possible to inherit only part of the aspects provided by the >superclass; it is impossible in most class-based languages to inherit >the behavior of a superclass (i.e. the methods) but not the >representation. While this may be strictly true, it is easily solved in class-based languages with multiple inheritance, such as CLOS. In such languages you can put the representations in one set of classes and the behavioral implementations in another set of classes. You would then define new classes that inherit one from column A and one from column B (am I coining a new metaphor, related to Flavors' use of "mixins"?), and only make instances of these classes. Implementing things this way requires extreme care. Normally, the code implementing the behavior of a class likes to have direct access to the representation of the class. In many OO languages the components of the representation ("slots" in CLOS, "instance variables" in Flavors and Smalltalk, "members" in C++, etc.) can be accessed directly as variables in the methods (in CLOS this requires use of the WITH-SLOTS macro, as methods are not attached to a single flavor so there is no built-in notion of "this" or "self"). In order to cope with the flexibility of the Chinese Menu style of OO programming you must take as much care in designing the internal interfaces of the classes as you do in designing the external interfaces. Separating out the interface specification can be done similarly, but it may require extra work. There can be a third set of classes that actually provide the externally visible interfaces. The interfaces to the above two sets of classes would not be available outside these three sets of classes (either using the language's visibility mechanisms or simply by adhering to naming conventions, e.g. calling the external interface FOO and the internal one FOO-INTERNAL). A particular specification class would only provide the interfaces that are part of the specification it models, but its implementations would simply pass the call on to the corresponding internal interface. In languages with explicit abstract superclasses you may be able to avoid the dual interfaces, and simply specify the interface in the abstract superclasses. Either way, the specification classes become column C in the class menu. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar