831059l@aucs.UUCP (Langlois) (11/27/88)
Is it possible to define a subclass that just adds some new methods
(and possibly some new instance variable of its own) to its superClass but
does not duplicate the instance variables of the superClass so that the new
methods access the superClass variables and not the subClass's inheritance of
the variable? My specific application is the development of a simulation
system. If I define a class Simulation with an eventQueue and a current time
and want to define a subClass Entity (objects of a simulation) but I want
Entity to access class Simulation's eventQueue and if possible, have no
eventQueue instance variable. Is my only option defining the two class as
subClasses of Object (or another class) so that instances of Entity don't
have an eventQueue.
Thanks for you time.
Steven Langlois UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!831059l
Acadia University BITNET: Steven@Acadia
Wolfville, NS Internet: Steven%Acadia.BITNET@CUNYVM.CUNY.EDU
CANADA B0P 1X0 barkley@unc.cs.unc.edu (Matthew Barkley) (12/11/88)
In article <1397@aucs.UUCP>, 831059l@aucs.UUCP (Steven Langlois) writes: > > Is it possible to define a subclass that just adds some new methods > (and possibly some new instance variable of its own) to its superClass but > does not duplicate the instance variables of the superClass so that the new > methods access the superClass variables and not the subClass's inheritance of > the variable? I have had similar problems with Smalltalk. They seem to come from the mis- conception that an instance of a class has anything at all to do with an in- stance of its superclass. In your example, one may have dozens of Entity instances (the class) and NO Simulation instances (the superclass). If I understand correctly, inheritance is static. That is, a class inherits all the function of the hierarchy above it, including variable names, but none of the *values* of the variables. I have posted this reply instead of e-mailing it because it may be wrong; if so, someone please post or mail a correction. Matt Barkley barkley@unc.cs.unc.edu Any opinions expressed are not necessarily shared by anyone else, and may not even be my own. How an organization can have an opinion is beyond me.
831059l@aucs.UUCP (Langlois) (12/13/88)
In article <5818@thorin.cs.unc.edu> barkley@unc.cs.unc.edu (Matthew Barkley) writes: >In article <1397@aucs.UUCP>, 831059l@aucs.UUCP (Steven Langlois) writes: >> >> Is it possible to define a subclass that just adds some new methods >> (and possibly some new instance variable of its own) to its superClass but >> does not duplicate the instance variables of the superClass so that the new >> methods access the superClass variables and not the subClass's inheritance of >> the variable? > >I have had similar problems with Smalltalk. They seem to come from the mis- >conception that an instance of a class has anything at all to do with an in- >stance of its superclass. In your example, one may have dozens of Entity >instances (the class) and NO Simulation instances (the superclass). If I >understand correctly, inheritance is static. That is, a class inherits all >the function of the hierarchy above it, including variable names, but none >of the *values* of the variables. I orginally posted this message because I wasn't sure of the organization of my classes for doing simulations as I was a Smalltalk newcomer. I suppose I wanted to keep my classes for doing simulations all in the same place (class and subclasses) because I didn't like the idea of having the classes spread throughout the system. When you make a change you have to possibly remember everything you've done like at a subclass to SortedCollection to implement a queue with statistics. It is true that Entities must know which is the current simulation they are running in, have access to simulation variables such as resources, distributions, etc., but it isn't logical for Entity to be a subclass of Simulation because an Entity is not a type of Simulation, it is an object that executes in the environment of a Simulation. In Smalltalk, it appears that a subclass is defined when you need greater functionality for an object or a group of objects. An example is a SortedCollection being a subclass of OrderedCollection because it provides greater functionality for the existing superclass. I later defined class Queue (sorted on priority of entities) which provides statistical gather capabilities to a SortedCollection, like how long entities spent waiting in the queue. I agree with what you say about inheritance of the hierarchy above, but it isn't logically correct to specify entities as subclass of simulations. Steven Langlois UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!831059l Acadia University BITNET: Steven@Acadia Wolfville, NS Internet: Steven%Acadia.BITNET@CUNYVM.CUNY.EDU CANADA B0P 1X0
toma@tekgvs.GVS.TEK.COM (Tom Almy) (12/15/88)
In article <1445@aucs.UUCP> 831059l@aucs.UUCP (Langlois) writes: >[...] I suppose I wanted to keep my classes for doing simulations all >in the same place (class and subclasses) because I didn't like the idea >of having the classes spread throughout the system. When you make a change >you have to possibly remember everything you've done like at a subclass to >SortedCollection to implement a queue with statistics. [...] This points out a deficiency of Smalltalk/V (which I am assuming Mr. Langlois is using) compared to Smalltalk-80. Smalltalk-80 has class categories, with every class being assigned a cateThis becomes the first level of selection in the browser. So you can write an application which has new subclasses of many existing classes, yet these new classes appear in the browser within a single category (presumably with your application name) rather than spread out in the class heirarchy. The existance of projects (with separately maintained change logs which can be browsed) is another big gain. Adding categories and modifying the browser shouldn't be too big a job, and it sure would help Smalltalk/V. Tom Almy toma@tekgvs.tek.com Standard Disclaimers Apply