ken@pdn.UUCP (Ken Auer) (10/27/87)
I recently came across this problem and thought I'd share it with you.
For you kids out there, don't try this at home... I'm a trained
professional... 8^)
I recently ran into an interesting problem when I subclassed the Point
class with a special-purpose pointer class (which had almost nothing to
do with Points except that it contained two numbers, and probably
shouldn't have been a subclass anyway but...). I had instances of a large
class which contained one or more instances of this new class
(DataSpecPointer) of which I needed to make copies. When I did, much to
my amazement my new copies now contained Points instead of
DataSpecPointers. Until recently, it never caused a problem, so when I
finally discovered that my copies were in such a state, I automatically
assumed the problem was one which I had found much more than once...
The original author of a class wrote some methods which referred to the
receiver's class by name instead of by 'self class'.
Numerous times, I've had to simply go in and change the line of code
that referred to the Class name, but this time I encountered a slightly
different situation. The Point>shallowCopy method looked like this:
shallowCopy
"Implemented here for efficiency"
^x @ y
The obvious fix was:
^self class x: x y: y
However, the Number>@ method calls a primitive (hence, the comment) which
returns a Point and, since Points are used all over the place, I thought it
not a good idea to make such a change. I've also found out there are many
other 'Point methods' which take advantage of the @ primitive.
(Benchmarking '1@2' vs. 'Point x: 1 y: 2' resulted in a 9 to 1
difference).
After deciding not to change the Point methods at the risk of performance,
I figured I could either override all the methods that used the @ in my
subclass, or reimplement DataSpecPointer as a subclass of Object. I chose
the latter since I was only really using about 4 methods from Point anyway
(and it probably shouldn't have been a subclass of Point in the first place).
However, if I was more heavily reliant on the Point class, it would have
been a real headache.
I'm using VI2.0, has this been implemented differently in later/other
versions? Does anybody have any other (er, better) solutions?
If not, the moral of this story is... don't subclass the Point class.
Does anybody know of any other classes that cause similar problems?
Although it could be fun to try to think up some brilliant solutions, I'm at
the point right now that I'd much rather avoid the problem in the
interest of saving time... after all that's why I'm using Smalltalk in the
first place.
--------------------------------------------------------------------------
Ken Auer Paradyne Corporation
{gatech,codas,ucf-cs}!usfvax2!pdn!ken Mail stop LF-207
Phone: (813) 530-8307 P.O. Box 2826
Largo, FL 34649-9981
"The views expressed above do not necessarily reflect the views of my
employer, which by no means makes them incorrect."