<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2995" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=406451117-29112006><FONT face="Trebuchet MS"
color=#0000ff size=2>Dear Ralph,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006><FONT face="Trebuchet MS"
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006> <FONT
face="Trebuchet MS" color=#0000ff size=2>have you considered just to insert an
abstract class for that prupouse?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006><FONT face="Trebuchet MS"
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006><FONT face="Trebuchet MS"
color=#0000ff size=2> 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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006><FONT face="Trebuchet MS"
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006> <FONT
face="Trebuchet MS" color=#0000ff size=2>cheers,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=406451117-29112006><FONT face="Trebuchet MS"
color=#0000ff size=2></FONT></SPAN><FONT face="Trebuchet MS" color=#0000ff
size=2></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" size=2><FONT
face="Trebuchet MS" size=2>Sebastian Sastre</FONT></DIV>
<DIV align=left>
<DIV align=left><FONT face="Trebuchet MS" size=2></FONT> </DIV>
<DIV align=left><A title=mailto:ssastre@seaswork.com.ar
href="mailto:ssastre@seaswork.com.ar"><FONT title=mailto:ssastre@seaswork.com.ar
face="Trebuchet MS" size=2>ssastre@seaswork.com.ar</FONT></A><FONT
face="Trebuchet MS" size=2> </FONT></DIV>
<DIV align=left><FONT face="Trebuchet MS" size=2>Seaswork </FONT></DIV>
<DIV align=left><I><FONT face="Trebuchet MS" size=2>Special Software
Solutions</FONT></I></DIV>
<DIV align=left> </DIV>
<DIV align=left><FONT face=Verdana size=1>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<SPAN class=643032423-05052005> por ningún medio
tecnológico</SPAN>. Las opiniones vertidas son responsabilidad del autor y no
son emitidas ni avaladas por <SPAN class=317392320-29042005>SEASWORK</SPAN>
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.</FONT></DIV></FONT><A title=http://www.seaswork.com.ar/
href="http://www.seaswork.com.ar/"></A></DIV>
<DIV> </DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=es dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B>
squeak-dev-bounces@lists.squeakfoundation.org
[mailto:squeak-dev-bounces@lists.squeakfoundation.org] <B>On Behalf Of
</B>Ralph Boland<BR><B>Sent:</B> Wednesday, November 29, 2006 12:19
PM<BR><B>To:</B> squeak-dev@lists.squeakfoundation.org<BR><B>Subject:</B>
abstract variables proposalQQ<BR></FONT><BR></DIV>
<DIV></DIV>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></BLOCKQUOTE></BODY></HTML>