[net.lang.st80] instance variable question

budd@arizona.UUCP (tim budd) (09/30/84)

Thanks for all of you who responded to my note on Little Smalltalk.

Here is a question that came up during the implementation of Little
Smalltalk.  Since my solution obviously differs from the Xerox solution, 
there must be something I am missing.

In st80, a subclass, say B, can manipulate instance variables in its
superclass, say A.  Suppose i is an instance variable name in the class A,
and a method in B uses i.  If we now edit the class description for A and
remove the instance variable i, what happens when we create a new
instance of B?

My solution in Little Smalltalk was to disallow methods for accessing
any but their own instance variables.  Obviously xerox has a different
solution, but I have not been able to discover, from reading the blue book,
what it is.

trow@uw-june.UUCP (10/06/84)

Forwarded from Smalltalk80Interest^@Xerox

----------------------------------------------------------------

Date: Fri, 5 Oct 84 16:08:35 PDT
From: McCall.pa
Subject: Re: instance variable question
To: arizona!budd@ucbvax (tim budd)
cc: Smalltalk80Interest^

You say: consider the situation in which we remove an instance variable
from a class, and some method in one of its subclasses refers to that
instance variable.  

You ask: What happens when we create an instance of the sublcass?

I ask: Why confuse the issue by talking about subclasses?  The problem
is essentially the same if we remove an instance variable from a class
which has methods refering to that variable (or to any other "higher
numbered" instance variables, for that matter).

There are two interrelated issues:
	(1) What happens to references to the old variable?
	(2) What do new instances of the newly created class look like?

The solution adopted in Smalltalk-80 (Xerox Smalltalk) is to "recompile"
the class.

The first time the old variable name is encountered, it is entered in a
special dictionary (which is listed in the global dictionary under the
name Undeclared).  This dictionary is similar in structure to the global
dictionary.  So the old instance variable has become, in essence, a
global variable (with the obvious problems if two different instances
want different values for that variable, which the writer of the code
thought was local to the instances.)  The only notification to the user
that such a change is taking place is the inclusion of 'xxx is
Undeclared' in the garbage being printed in the System Transcript (where
'xxx' is the name of the old instance variable.)

This "solution" extends smoothly (if slowly) to include your case in
which the variable is refered to by methods in subclasses.  Simply
recompile the methods in the subclasses as well.

Since references to the lost variable now refer to a global and all
other instance variable offsets have been revised by the recompilation,
new instances of the class (or of its subclasses, as you wondered) can
be shorter (omitting the deleted variable.)

----------------------------------------------------------------

trow@uw-june (Jay Trow) (10/09/84)

Forwarded from Smalltalk80Interest^@Xerox.arpa

----------------------------------------------------------------

Date: Mon, 8 Oct 84 8:52:48 PDT
From: krasner@xerox.arpa
Subject: Re: instance variable question

Restricting classes to use only the instance variables defined in them
and not in their superclass will result in making inheritance almost useless.
Inheritance for us has proven to be significantly more powerful than the
ability to change class definitions.  So given the trade-off between
restricting the power of inheritance and longer execution time for re-defining
classes, I would recommend that you opt for the latter, as described in
Kim McCall's message.

The entire Smalltalk-80 system source code is part of the ($400 for
universities) license package.  Reading the sources would help you answer
some of these types of questions.  You do not necessarily have to have a
running system to browse the code--at least one of our licensees, for example,
was able in about a week to write a reasonably powerful Unix tool to browse
the code before their system was widely available.  I recommend you try to
get a license for U. of Arizona; let me know if you need more details on how.

Glenn Krasner

----------------------------------------------------------------

trow@uw-june (Jay Trow) (10/09/84)

Forwarded from Smalltalk80Interest^@Xerox.arpa

----------------------------------------------------------------

Date: Sat, 6 Oct 84 16:13 PDT
From: doherty.pasa
Subject: Re: instance variable question

	Not allowing methods to access instance variables of their superclasses
seems like a terrible thing to do.  It hurts the whole inheritance scheme,
and is really unneccessary.  When you change the definition of a class, the
Xerox implementation recompiles all of its subclasses.  Your example (of
subclass B using class A's instance variable i and subsequently changing i)
would result in a syntax error, which would open a syntax error window on the
bogus method to allow you to edit the method or abort the change.

----------------------------------------------------------------

jeh@ritcv.UUCP (Jim Heliotis) (10/09/84)

> 
> The solution adopted in Smalltalk-80 (Xerox Smalltalk) is to "recompile"
> the class.
> 
OK, I understand what happens IF you recompile the class (BTW, when does
the error message get printed, during compilation, or execution?), but what
if you do not recompile?  Is it as if the variable had not been deleted, or
is recompilation automatic when there is a change to a class's variables?

				Jim Heliotis
				{allegra,seismo}!rochester!ritcv!jeh
				rocksvax!ritcv!jeh
				ritcv!jeh@Rochester

trow@uw-june.UUCP (10/19/84)

Forwarded from Smalltalk80Interest^@Xerox.arpa

----------------------------------------------------------------

Date: Fri, 12 Oct 84 9:07:37 PDT
From: Krasner.pa
Subject: Re: instance variable question
To: ritcv!jeh@rochester
cc: Smalltalk80Interest^

> BTW, when does the error message get printed, during compilation,
> or execution?

The error message ("foo is undeclared") is written in the system transcript
during (re)compilation.

> but what if you do not recompile?  Is it as if the variable had not been
> deleted, or is recompilation automatic when there is a change to a class's
> variables?

If you do not recompile then your system may blow up.  Example, a class has
instance variables a, b, c, d, and e, and you remove b without recompiling.
The Smalltalk-80 bytecode specification says that instance variable references
are compiled into indexes, and that no bounds checks are performed for instance
variable loads or stores.  New instances will have only four fields, but the
code for accessing c, d, and e would continue to say 3rd, 4th, and 5th field.
The first two will access the wrong field of the object, the last will
access some memory not in this object.

Therefore, recompilation is required when a class's variables change, and is
automatic when that change is invoked in either of the two standard ways in
the system, via a browser or a file-in.  In addition to recompilation, all
existing instances are transformed into new-form instances via "become".

Glenn Krasner
SCL/PARC (krasner.pa@Xerox)

----------------------------------------------------------------