Path: utzoo!attcan!uunet!husc6!psuvax1!rutgers!rochester!cornell!uw-beaver!tektronix!reed!bart From: bart@reed.UUCP (Bart Massey) Newsgroups: comp.lang.smalltalk Subject: Re: Is SELF a naughty OOP construct? Message-ID: <9438@reed.UUCP> Date: 1 Jun 88 08:49:21 GMT References: <1620001@hplb29a.HPL.HP.COM> <3313@pdn.UUCP> <2689@tekcrl.TEK.COM> Reply-To: bart@reed.UUCP (Bart Massey) Organization: Reed College, Portland OR Lines: 32 In article <2689@tekcrl.TEK.COM> brianw@tekcrl.UUCP (Brian Wilkerson) writes: > I would argue that any code sending a message to 'super' (other than the > one being overridden) should be highly suspect. Chances seem very good > that it will reduce the amount of code that can be inherited by subclasses > by forcing them to override the method containing the send to 'super' in > order to affect an override of the message being sent to 'super'. Agreed. But the special case you mention -- invoking the "old" behavior of a method to do most of the work -- covers most of the usages of super that I've seen in actual code. Perhaps what is wanted is something more restricted. Something like Object Pascal's "inherited" operator. Imagine that e.g. newOn: bletch ^ (overridden newOn: bletch) setSubclassInstVar: nil is legal, but newOn: bletch ^ (overridden new on: bletch) setSubclassInstVar: nil is not. I guess the semantics of the "overridden" pseudo-object are that it responds to at most one message -- the selector and method for this message being the selector and method overridden by the current method definition. Given this psuedo-object, I think I'd happily sacrifice the "super" pseudo-object. Am I wrong? Am I missing something important? Am I totally confused? Only my hairdresser knows for sure... Bart