[squeak-dev] References to a class implementing a given method in
the method
Ralph Boland
rpboland at gmail.com
Sat Jan 23 03:08:34 UTC 2010
When I have a method that is applied to instances of a class X that do
not depend on
the values of the instances themselves I place those methods on the
class side.
For the problem at hand the method takes as input a collection of the
instances of
the class and rearranges them in some way:
Such a method might be called:
rearrange: aCollection
(Actually I lied; the rearrange method depends upon probability
values stored in instances of X)
To get an instance of the object to do the rearranging (i.e. X) on the
instance side of X I have a method:
rearranger
^self class
This works fine so far but in this particular case X
has subclasses and the collection passed to the method
"rearrange:" is not impacted by the fact that instances of
the subclasses of X may be in the Collection; i.e. everything
still works.
However, if I send the "rearranger" message to an instance of
a subclass Y of X then -- well ok; everything still works.
Everything still works because the "rearranger" message now
returns a subclass of X which in turn inherits
the "rearrange:" method from class X.
My only complaint then is that every time the "rearrange:"
message is sent inheritance must now be used to find the
"rearrange:" method.
This seems inefficient to me (I know Squeak is 50 slower than
C so who cares) so to fix this I can change method "rearranger"
to:
rearranger
^X "the class X that is"
Problem fixed.
However, I have been taught that now the code is written in
a brittle i.e. bad way. That is, if I now rename class X to
Z then the "rearranger" method becomes broken.
Finally, a question:
How do I write the method "rearranger" so that it returns
the class in which the method is defined rather than the class
of the object that received the "rearranger" message?
I am looking for something clean here; I can think of some
convoluted ways of doing this.
I admit that even if this can be done cleanly the code remains
more brittle than the original solution. This is because
if a subclass of X wants to override method "rearrange:"
it must now also override method "rearranger" which was
not necessary with the original solution.
I am also aware that optimizations are done by the VM to
avoid method lookups but I am not sure of the details.
Do the details mean that after the first send of "rearrange:"
to class Y no further lookups are needed on subsequent
sends? to Y.
What if "rearrange" is sent to Y from multiple
locations in some method or from multiple methods in some class
all sending to the same instance variable holding Y?
Regards,
Ralph Boland
More information about the Squeak-dev
mailing list
|