Path: utzoo!attcan!uunet!dalcs!aucs!831059l
From: 831059l@aucs.UUCP (Langlois)
Newsgroups: comp.lang.smalltalk
Subject: Re: Duplication of instance variables in subclasses
Message-ID: <1445@aucs.UUCP>
Date: 13 Dec 88 13:23:36 GMT
References: <1397@aucs.UUCP> <5818@thorin.cs.unc.edu>
Reply-To: 831059l@aucs.UUCP (Langlois)
Distribution: na
Organization: School of Computer Science, Acadia Univ., Nova Scotia
Lines: 43

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