abstract variables proposalQQ
azreal1977 at hotmail.com
Wed Nov 29 18:09:40 UTC 2006
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
>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
>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
> that uses b, while if option 1) is used, the methods need be
>only in class B.
> (Admitted this causes the methods to be accessible by classes D and E
> 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
>variables of the class B would declare b (and c) as abstract instance
>(The same approach would be applied for class variables.)
>No space is allocated for variable b so instances of B could not access
>Nevertheless it would then be possible to write methods of class B that
>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
>not connected to class B but instead two copies of the byte codes for M
>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
>Option 2) however, and is in fact better since only one copy of the source
>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
>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
>versions of Q installed in their list of methods. One approach would be
>the method Q in these subclasses as:
> super Q'
>In order to make it clear that a method is abstract I think the abstract
>of the method would need to be made more visible such as by making them
>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
>I am interested in hearing comments on whether this proposal is good or bad
>I would also like to have pointed out some of the more significant
>of implementing this proposal.
>Thanks for listening.
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001
More information about the Squeak-dev