abstract variables proposalQQ

Ralph Boland rpboland at gmail.com
Wed Nov 29 14:18:51 UTC 2006


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061129/db24084a/attachment.htm


More information about the Squeak-dev mailing list