First of all, the problem you describe isn't a smalltalk issue.  It is an 
object oriented issue.  And as most OO people would probably do, I have to 
ask:  If classes deriving from some super don't need the instance variables 
of their parent, then are you *sure* the inheritance hierarchy is right?

I certainly appreciate proposals for new ideas, and I don't want to sound 
too negative.  It's just that you propose to add complexity for a problem I 
have never had in 10 (or so) years of OO development. :)


>From: "Ralph Boland" <rpboland at gmail.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org
>Subject: abstract variables proposalQQ
>Date: Wed, 29 Nov 2006 09:18:51 -0500
>
>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


>

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered 
by Pandora http://radio.msn.com/?icid=T002MSN03A07001