Dear Ralph,
 
    have you considered just to insert an abstract class for that prupouse?
 
    I can think in a trivial solution for you request in wich you make an abstract
subclass of B that is parent of C and D in wich you can define it's common instVar b.
 
    cheers,
 
Sebastian Sastre
 
 <mailto:ssastre at seaswork.com.ar> ssastre at seaswork.com.ar 
Seaswork 
Special Software Solutions
 
Este mensaje y sus adjuntos son confidenciales y de uso exclusivo para el usuario a quien
esta dirigido. Puede contener información amparada por el secreto profesional. Si Ud. no
es el destinatario especificado no debe copiar, enviar o utilizar ninguna parte del mismo
y/o de sus adjuntos por ningún medio tecnológico. Las opiniones vertidas son
responsabilidad del autor y no son emitidas ni avaladas por SEASWORK a menos que se
indique claramente lo contrario y que la identidad y autoridad del autor, para comprometer
a nuestra empresa, puedan ser verificados. No se garantiza la integridad de los mensajes
enviados por e-mail ni que los mismos sean enviados en termino, o que no contengan errores
o virus. El emisor no aceptara responsabilidad por los errores, modificaciones u omisiones
que resulten en el mensaje, bajo la hipótesis de que pudo ser modificado.
 <http://www.seaswork.com.ar/> 
 


  _____  

From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Ralph Boland
Sent: Wednesday, November 29, 2006 12:19 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: abstract variables proposalQQ


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/6fe62713/attachment.htm