831059l@aucs.UUCP (Langlois) (11/09/88)
I'm a little confused about defining new classes in Smalltalk/V.
When you choose to add a subclass to an existing class, you are then asked
to select from a menu containing subclass, variableSubclass,
variableWordSubclass, and variableByteSubclass. I've read the description
in the manual but I am still confused. When do you choose which?
Any help in clearing this up would be greatly appreciated.
Steven Langlois UUCP: {uunet|watmath|utai|garfield}!dalcs!auc!831059l
Acadia University BITNET: Steven@Acadia
Wolfville, NS Internet: Steven%Acadia.BITNET@CUNYVM.CUNY.EDU
CANADA B0P 1X0 elt@entire.UUCP (Edward L. Taychert) (11/16/88)
In article <1361@aucs.UUCP>, 831059l@aucs.UUCP (Langlois) writes: > > I'm a little confused about defining new classes in Smalltalk/V. > When you choose to add a subclass to an existing class, you are then asked > to select from a menu containing subclass, variableSubclass, > variableWordSubclass, and variableByteSubclass. I've read the description > in the manual but I am still confused. When do you choose which? > Any help in clearing this up would be greatly appreciated. use variableSubclass, this means that object instance variable can reference any kind of object. That's kind of what smalltalk is all about. If however you want (or need) high speed access to, say a byte array, you can make an object variableByteSubclass. The object created will only know how to access bytes, but will do so much faster. Now there is a trick here that I'm tring to remember... I don't think that byte and word subclasses have instance variables per se, after you create one, use at: and at:put: to reference it. Honestly, I just played around until I got it to work the way I wanted it to. Don't be shy about calling Digitalk customer support. If you don't have the number, call LA,Ca information and ask for it. They are very helpful, never question your smalltalk skills (which is important if you're shy like me) and if they can't give you an answer on the spot, really do call you back. -- ____________________________________________________________________________ Ed Taychert Phone: USA (716) 381-7500 Entire Inc. UUCP: rochester!rocksanne!entire!elt 445 E. Commercial Street East Rochester, N.Y. 14445 _____________________________________________________________________________
adamsf@rpics (Frank Adams) (11/18/88)
In article <3269@entire.UUCP> elt@entire.UUCP (Edward L. Taychert) writes: >In article <1361@aucs.UUCP>, 831059l@aucs.UUCP (Langlois) writes: >> When you choose to add a subclass to an existing class, you are then asked >> to select from a menu containing subclass, variableSubclass, >> variableWordSubclass, and variableByteSubclass. > >use variableSubclass, this means that object instance variable can reference >any kind of object. This is not, in general, good advice. For most classes, you should choose just plain subclass. This means that the instance variables of the instances of the class will all have names. These named instance variables can each reference any kind of object. Use the variable* forms only for things like arrays which are going to maintain a list of members. Even then, consider whether it wouldn't be better to have, say, an instance variable which always contains an array instead of indexed instance variables. #! rnews
elt@entire.UUCP (Edward L. Taychert) (11/22/88)
>In article <1361@aucs.UUCP>, 831059l@aucs.UUCP (Langlois) writes: >> In article <3269@entire.UUCP> elt@entire.UUCP (Edward L. Taychert) writes: >> ... >> use variableSubclass, this means that object instance variable can reference >> any kind of object. > > This is not, in general, good advice. For most classes, you should choose > just plain subclass. This means that the instance variables of the instances > of the class will all have names. These named instance variables can each > reference any kind of object. > > Use the variable* forms only for things like arrays which are going to > maintain a list of members. Even then, consider whether it wouldn't be > better to have, say, an instance variable which always contains an array > instead of indexed instance variables. In general, I think this is true. If your object will never be referred to like an array, "subclass" is correct. I recommended "variableSubclass" because it is the most general type of class. Using "variableSubclass" means that the object will respond to "new:", "at:" and "at:put:". Using "subclass", it will not. However, as Langlois points out, you may implement these methods yourself within the class. Doing so, however, adds a level of indirection which will slow you down `a little bit'. According to Digitalk customer support, there is no penalty in speed or memory for using "variableSubclass", even if you don't use its indexing capabilities. There is a potential risk, however, for using it blindly: If you implement a variable subclass of a object which is not variable and the super class implements (let's say) at:, the superclass's at: will not be inherited. I'm told that V286 changed class OrderedCollection from "variableSubclass" to "subclass". Creating a variable subclass of V286's OrderedCollection would probably be an error. If you use "variableSubclass", the object may contain named instance variables (pointers) of any object type and its `built in' array may contain objects of any type also. If you use "variableWordSubclass" or "variableByteSubclass:" the object cannot contain named instance variables and the array elements cannot refer to general objects, only words or bytes. Methods other than at: and at:put: will contain lines like "self at: 7" to operate on its contents. -- ____________________________________________________________________________ Ed Taychert Phone: USA (716) 381-7500 Entire Inc. UUCP: rochester!rocksanne!entire!elt 445 E. Commercial Street East Rochester, N.Y. 14445 _____________________________________________________________________________