mongoose@spf.trw.com (Julian Watkins) (05/16/91)
I am porting some st80 code that was originally done by modifying Analyst Spreadsheet classes rather than by subclassing them. I am attempting to remedy this situation by creating subclasses that override only the methods that really need to be overridden. One problem I am getting is that I have to override methods that call methods in the superclass. This is easy to do by using the pseudo-variable "super". The problem is that I end up calling the method that exists in the immediate superclass (the one I just subclassed from) rather than ITS superclass. Maybe an example would suffice: Matrix variableSubclass: #SpreadsheetHolder SpreadsheetHolder variableSubclass: #MySpreadsheetHolder When I override a method from SpreadsheetHolder in MySpreadsheetHolder, I would like to access methods that really exist within Matrix. If I use "super" I get methods that are in SpreadsheetHolder. My current work around is to create methods in SpreadsheetHolder that do nothing but call the method in "super" that I need to use in MySpreadsheetHolder. My question is: Is this the only way to do what I want? Am I missing the boat somewhere? Should I try to restructure the class hierarchy so that there never is a case where this needs to happen? Direct E-mail is fine, unless this seems to be a topic that could use some open discussion. -- Julian J. Watkins 213-813-6516 watkins@spf.trw.com
kentb@argosy.UUCP (Kent Beck) (05/16/91)
For example:
A superclass: Object
A>>initialize
...
B superclass: A
B>>initialize
...
super initialize
C superclass: B
C>>initialize
...
A's initialize, but not B's
The program transformation I use in this case is to break A>>initialize
into submethods (i.e. initialize sends "self initializeFoo"), then
C>>initialize can send "self initializeFoo" instead of "super initialize".
In practice I find that this situation arises when I have one method doing
too many things, so the resulting code is cleaner and easier to
understand.
Kentsusser@Apple.COM (Joshua Susser) (05/25/91)
In article <28319BCD.B2F@deneva.sdd.trw.com> mongoose@spf.trw.com (Julian Watkins) writes: > I am porting some st80 code that was originally done by modifying Analyst > Spreadsheet classes rather than by subclassing them. [...discussion of problem omitted...] Class Object has a number of messages that are overridden, that you still want to be able to get to directly. "new" is a good example of this. The provision for allowing direct access to the functionality of new without mucking about in the methods implemented in the intermediate ancestors was to create a "basicNew" method that does the same thing. So even though "new" is overridden, you can still always get to "basicNew". So if you have a message "spam" in Matrix, move the body of the method to "basicSpam", and change "spam" to just do "^self basicSpam". Then your subclass can say "super basicSpam" anywhere it needs to bypass the code in SpreadsheetHolder. By the way, what *are* you doing that needs to get directly to methods in Matrix? I seem to remember the only behavior SpreadsheetHolder inherits from Matrix is the various atXXX: and atXXX:put: accesing methods. I guess I should have made SpreadheetHolder be a subclass of Object with a Matrix in an instance variable, and then you wouldn't have to muck about with all this bypassing and disinheritance. Sorry, but I had only been programming in Smalltalk a few weeks when I started the design. But next time I'll know... Joshua Susser, Object Percussionist Apple Computer, Advanced Technology Group inet: susser@apple.com | link: susser.j | phone: 408/974-6997 Macintosh Jr. - The power to crush the other kids.