Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!nike!ucbcad!ucbvax!hplabs!tektronix!reed!mdr
From: mdr@reed.UUCP (Mike Rutenberg)
Newsgroups: net.lang.st80
Subject: Re: HELP, Smalltalk problems
Message-ID: <3779@reed.UUCP>
Date: Tue, 1-Jul-86 22:37:11 EDT
Article-I.D.: reed.3779
Posted: Tue Jul  1 22:37:11 1986
Date-Received: Fri, 4-Jul-86 02:05:48 EDT
References: <9500001@uiucdcsb>
Reply-To: reed!tektronix!BAtkinson.pa@Xerox.Arpa (Bob Atkinson)
Organization: Reed College, Portland, Oregon
Lines: 75

In article <9500001@uiucdcsb> graver@uiucdcsb.CS.UIUC.EDU writes:
>
>I am working with Ralph Johnson on building a type system for Smalltalk-80,
>and we have run into some problems.  (By the way, we are running Smalltalk-80
>on the Tektronix 4404.)  Most of the difficulties arise when we attempt to
>add instance variables to classes with many instances (e.g. ClassDescription,
>MethodDictionary, etc.).  In the case of ClassDescription, we tried to add
>an instance variable which required that every class be recompiled.  When the
 
I tried that once too, when I was working on my type system for
Hurricane, an optimizing compiler that I built.  To make an
understatement, adding an instance variable to something like
ClassDescription is very difficult.  Your image is probably
significantly different enough than the one that I have been using that
I couldn't tell you how to do it, but one will have to be very sneaky.
I eventually gave up and make a separate data structure, which in some
ways was a better idea, but I still would have liked to get that
"typeDelarations" variable in all the classes.

This was a long time ago (bout a year and a half) and I dare say if I gave
it a try again I could manage to pull it off.  It would probably involve
some very wierd putting the classes in wierd states as the update was going
on.  Poke around in the class creation messages and see exactly what
happens.

...
>ary we encountered a quite different problem.  MethodDictionary was recompiled
...
>
>	oldClass allInstances do:
>		[:old | ...
>		old become: new]
...
>object pointers are swapped with the "become:" message.  The problem occurred
>when "become:" tried to swap the object pointers for the MethodDictionary that
>contains the definition for the "become:" message.  We are thrown out of the
>
>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.

Yes, I am sure that these classes are special. Some of them even have
known oops.  (See the blue book)  It is not impossible to do what you
wish to do, but I almost guarentee that the standard, existing every
day code will not work in this particular case.  You are really going
to have to get your hands dirty.

>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 feasable?  Unless these problems can be

That is one of the main reasons that the SystemTracer was built in the
first place.  By all means, that is a possible solution, and probably
the easiest from your point of view.  I hope your tracer works:  I have
yet to see one that does, though I have been told that they exist :-).
Try to make a simple clone image first and find out.

>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.

This also might have some dangerous intermediate state conditions.  Be 
careful.

>Has anyone come across these problems before?  Has anyone found any solutions?

Most certainly. See above.

>		Justin Graver

	-bob atkinson
	BAtkinson.pa@Xerox.com
	BAtkinson.pa%xerox.com@csnet-relay.csnet
		or something like that. Get to the arpanet
		and you'll be fine.