Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!lll-crg!nike!ucbcad!ucbvax!hplabs!tektronix!tekcrl!brianw
From: brianw@tekcrl.UUCP (Brian Wilkerson)
Newsgroups: net.lang.st80
Subject: Re: HELP, Smalltalk problems
Message-ID: <824@tekcrl.UUCP>
Date: Mon, 7-Jul-86 18:38:39 EDT
Article-I.D.: tekcrl.824
Posted: Mon Jul  7 18:38:39 1986
Date-Received: Wed, 9-Jul-86 02:18:44 EDT
References: <9500001@uiucdcsb>
Organization: Tektronix, Inc., Beaverton, OR
Lines: 59


Justin Graver wrote:

> We have a suspicion that the interpreter may assume certain things about some
> fundamental classes and that adding instance variables as described above may
> be impossible.  It would be helpful if someone could confirm or deny this.

Unfortunately, your suspicions are correct.  The interpreter does depend on
the format of certain  objects since they are  accessed by the  interpreter
directly.  The  classes MethodDictionary, Behavior  and CompiledMethod  are
examples of  these.   Interpreter accesses  to these  objects rely  on  the
position of instance variables within the  object, rather than the name  of
the variable.   This means that  new instance variables  can only be  added
after all instance variables (named or indexable) used by the interpreter.

I know of  no way  (in the  standard image)  to add  instance variables  to
MethodDictionary.  The interpreter always allocates memory for an object in
such a way that named instance variables come first (in the order declared,
starting with  class  Object and  ending  with  the class  of  the  object)
followed by  indexed  instance  variables.    Since  MethodDictionary  uses
indexed variables  to  store  the  key (method  selector),  and  since  the
interpreter must perform method look-up by name (selector), the interpreter
must know where the  indexed instance variables begin.   This prevents  the
addition of named  instance variables.   Subclassing MethodDictionary  will
not work either (for the  same reason).  It  will probably be necessary  to
store the information you hoped to store with the method dictionaries  with
the class instead.

For a more complete explanation  of how and why  these classes are used  by
the interpreter, and  an indication  of the  classes and  objects that  are
directly used  by  the interpreter,  see  section  four of  the  Blue  Book
("Smalltalk-80: The Language and Its Implementation", Adele Goldberg, David
Robson, Addison-Wesley, 1983, pp.541-688).

> We have also considered using the system tracer to modify such large classes,
> but feel that this may be an unreasonable solution.  Has anyone ever used the
> tracer for such a purpose and is it feasible?

The system tracer can be used for this purpose, but doing so may require  a
great deal of effort  on your part (depending  on the specific changes  you
try to make).  It has been successfully used here at Tektronix for  similar
types of changes.   The system tracer  should allow you  to get around  the
"Too many objects" error you encountered.

>                                                Unless these problems can be
> solved, our present solution is to change the meaning of existing instance
> variables (for example, a list could easily become a list of ordered pairs or
> ordered triples) or to build each "new" class from scratch.

Again, changing the meaning of instance variables in these special  classes
is dangerous, at best.   The interpreter not  only makes assumptions  about
the format of the instances of these classes, but may also make assumptions
about the type of values stored in those instance variables.  (For example,
when performing method  look-up, the interpreter  assumes the  'methodDict'
field in Behavior points to an instance of the class MethodDictionary.)

Brian Wilkerson
   brianw@tektronix.UUCP
   ..!tektronix!tekchips!brianw