werner@tnoibbc.UUCP (Werner de Bruijn) (02/07/90)
Does anyone know how a view on a class can be implemented? The idea comes from database environments where instances of a class can be derived from instances of other classes. The main problem I see is how to handle the 'typeof' or 'isit' message. -- Werner de Bruijn TEL : (31) 15-842040 IBBC-TNO FAX : (31) 15-843990 P.O. Box 49 UUCP : ..!hp4nl!tnoibbc!werner 2600 AA Delft, the Netherlands USENET : werner@tnoibbc
UH2@psuvm.psu.edu (Lee Sailer) (02/09/90)
In article <1385@tnoibbc.UUCP>, werner@tnoibbc.UUCP (Werner de Bruijn) says: > >Does anyone know how a view on a class can be implemented? The idea comes >from database environments where instances of a class can be derived from >instances of other classes. Right off, I can think of two ways, assuming that I understand what you mean by "views." The simple case is where there is an object, say anEmployee, and you want some users to only have access to certain of anEmployees attributes and methods. Just create a subclass of anEmployee, say aRestrictedEmployee. Use stubs to hide those methods that need to be hidden, recode those methods that need more or less security, create new PrintAs or DisplayAs methods, and so on. In the database world, views are often complicated joins of many types of thing. In this case, systems with multiple inheritance would work better than those with single. Of course, the usual tricks for simulating multiple inheritance like behavio should still work. lee
benson@blake.acs.washington.edu (Dan Benson) (02/09/90)
In article <90039.113649UH2@PSUVM.BITNET> UH2@psuvm.psu.edu (Lee Sailer) writes: > >In the database world, views are often complicated joins of many types >of thing. In this case, systems with multiple inheritance would work >better than those with single. Of course, the usual tricks for >simulating multiple inheritance like behavio should still work. > I'm not familiar with the "usual tricks" you refer to. Sounds interesting. Could you please elaborate? Thanks Dan -- | Dan Benson benson@ee.washington.edu | | Dept. of Elec. Engr., FT-10 | | University of Washington | | Seattle, WA 98195 |
UH2@psuvm.psu.edu (Lee Sailer) (02/13/90)
In article <5668@blake.acs.washington.edu>, benson@blake.acs.washington.edu (Dan Benson) says: > >In article <90039.113649UH2@PSUVM.BITNET> UH2@psuvm.psu.edu (Lee Sailer) : >writes >> >>In the database world, views are often complicated joins of many types >>of thing. In this case, systems with multiple inheritance would work >>better than those with single. Of course, the usual tricks for >>simulating multiple inheritance like behavio should still work. >> >I'm not familiar with the "usual tricks" you refer to. Sounds interesting. >Could you please elaborate? Thanks > It's a kludge. Suppose you want anX to inherit from both aY and aZ, but your language doesn't have multi-inheritance. Create anX as a subclass of aY, and give it an attribute of type aZ (or a message that returns aZ, or whatever). This can be extended to anA, aB, aC, etc, of course. To utilize anX's Z-like behavior, you cannot just send a message to anX. You have to send it to the X's aZ. The overhead is mostly in the head of the programmer, which is too bad, since that is the kind of overhead OOP is supposed to reduce. Try Eiffel 8-). lee