One of my fustrations in using Smalltalk is that I may have a subclass B with a number
of subclasses, say C,D,E,F and such that some of the subclasses, say C and D,
need to access an instance variable, say b, but the remainding classes, say E and F,
do not need to access variable b. In this situation I have two basic options:

1) Declare variable b in class B.
      The problem then is space is allocated for variable b in classes D and E as well.

2) Declare variable b   in classes C and D.
     A minor problem here is that I need to declare b for each class
     which uses b rather than just once.
     The major problem is that methods that access b   must be written in each class
     that uses b, while if option 1) is used, the methods need be declared only in class B.
     (Admitted this causes the methods to be accessible by classes D and E as well
      which is not desirable but is usually acceptable.)

I propose that Smalltalk (Squeak) allow the declaration of abstract variables as follows:

A line of the form abstractInstanceVariableNames: 'b c' in the definition of the
variables of the class B would declare b (and c) as abstract instance variables.
(The same approach would be applied for class variables.)
No space is allocated for variable b so instances of B could not access them.
Nevertheless it would then be possible to write methods of class B that accessed
variable b.   Let M be method of B that accesses b (but not c).
Alas, instances of B cannot use method M since M is an abstract method.
(Abstract methods are methods that access abstract instance variables)

Now, in subclasses of B, it is allowable to define instance variable b.
Once this is done method M becomes accessible
to the instances of the subclasses of B for which b has been declared.
For example if classes C and D declare instance variable b
while classes E and F do not then instances of classes C and D
can use method M but instances of classes E and F cannot use method M.

In terms of implementation it should be noted that the byte codes for M are
not connected to class B but instead two copies of the byte codes for M are created
with one placed with class C and the other placed with class D.
The bad side of this is obviously the duplication of code. This is no worse than
Option 2) however, and is in fact better since only one copy of the source is created.
Option 1) remains in circumstances where it is warranted.

It is noteworthy, also, that access to method M is faster than with Option 1) because
less searching of the inheritance chain is needed to find M. This presents a problem:
Users wanting fast access to a method N of B that is not abstract by subclasses of B
could artificially make N abstract by having it access b as in
'true ifFalse: [b <- b].'.
This is ugly of course. What is needed is a way to define a method, say Q, of B
as abstract even though it does not access any abstract variables.
Subclasses of B that want to access Q would need to state that they want a concrete
versions of Q installed in their list of methods. One approach would be to write
the method Q in these subclasses as:

'Q
super Q'

In order to make it clear that a method is abstract I think the abstract variables
of the method would need to be made more visible such as by making them bold
or red or both.

Clearly I haven't worked out all of the syntax needed for my proposal but
it seems not so difficult.
More difficult of course is the determining the ramifications of implementing
this proposal.

I am interested in hearing comments on whether this proposal is good or bad
and why.
I would also like to have pointed out some of the more significant ramifications
of implementing this proposal.

Thanks for listening.

Ralph