One of my fustrations in using Smalltalk is that I may have a subclass B with a number<br>of subclasses, say C,D,E,F and such that some of the subclasses, say C and D, <br>need to access an instance variable, say b, but the remainding classes, say E and F,
<br>do not need to access variable b. In this situation I have two basic options:<br><br>1) Declare variable b in class B.<br> The problem then is space is allocated for variable b in classes D and E as well.
<br><br>2) Declare variable b in classes C and D.<br> A minor problem here is that I need to declare b for each class <br> which uses b rather than just once.<br> The major problem is that methods that access b must be written in each class
<br> that uses b, while if option 1) is used, the methods need be declared only in class B.<br> (Admitted this causes the methods to be accessible by classes D and E as well <br> which is not desirable but is usually acceptable.)
<br><br>I propose that Smalltalk (Squeak) allow the declaration of abstract variables as follows:<br><br>A line of the form abstractInstanceVariableNames: 'b c' in the definition of the<br>variables of the class B would declare b (and c) as abstract instance variables.
<br>(The same approach would be applied for class variables.)<br>No space is allocated for variable b so instances of B could not access them.<br>Nevertheless it would then be possible to write methods of class B that accessed
<br>variable b. Let M be method of B that accesses b (but not c).<br>Alas, instances of B cannot use method M since M is an abstract method.<br>(Abstract methods are methods that access abstract instance variables)
<br><br>Now, in subclasses of B, it is allowable to define instance variable b.<br>Once this is done method M becomes accessible <br>to the instances of the subclasses of B for which b has been declared. <br>For example if classes C and D declare instance variable b
<br>while classes E and F do not then instances of classes C and D <br>can use method M but instances of classes E and F cannot use method M.<br><br>In terms of implementation it should be noted that the byte codes for M are
<br>not connected to class B but instead two copies of the byte codes for M are created<br>with one placed with class C and the other placed with class D.<br>The bad side of this is obviously the duplication of code. This is no worse than
<br>Option 2) however, and is in fact better since only one copy of the source is created.<br>Option 1) remains in circumstances where it is warranted.<br><br>It is noteworthy, also, that access to method M is faster than with Option 1) because
<br>less searching of the inheritance chain is needed to find M. This presents a problem:<br>Users wanting fast access to a method N of B that is not abstract by subclasses of B<br>could artificially make N abstract by having it access b as in
<br> 'true ifFalse: [b <- b].'. <br>This is ugly of course. What is needed is a way to define a method, say Q, of B<br>as abstract even though it does not access any abstract variables. <br>Subclasses of B that want to access Q would need to state that they want a concrete
<br>versions of Q installed in their list of methods. One approach would be to write<br>the method Q in these subclasses as:<br><br> 'Q<br> super Q'<br><br>In order to make it clear that a method is abstract I think the abstract variables
<br>of the method would need to be made more visible such as by making them bold<br>or red or both.<br><br>Clearly I haven't worked out all of the syntax needed for my proposal but<br>it seems not so difficult.<br>More difficult of course is the determining the ramifications of implementing
<br>this proposal.<br><br>I am interested in hearing comments on whether this proposal is good or bad<br>and why.<br>I would also like to have pointed out some of the more significant ramifications<br>of implementing this proposal.
<br><br>Thanks for listening.<br><br>Ralph<br><br><br><br><br>