**> On Tue, 19 Jul 94 16:46:53 -0700, Bruce McKenzie bruce@trwlasd.com said: [ more deleted ]

I would not complicate the implementation for consistency unless there was a real gain. I can imagine some pretty useless stuff ( I suggested method parents about two years ago :-) :

[deleted] Bruce> possibility of implementing a conscience for an object. Namely, Bruce> "Normally, I implement all setPosition:: messages, but when the system Bruce> is in a 'panic' state, I ignore them." (implying that "setPosition::" Bruce> is a family of messages, and you don't want to put the same state Bruce> checking code in each one)

Bruce> Objective-C provides capabilities to do this, but it would be a bit of Bruce> a hack.

Bruce> Does this sound useful? Have people experimented with this?

Oh yes, it's useful. It can be used in time-critical computing scenarios to handle different ways of implementing things -- e.g., the fast-but-sloppy way versus the slow-but-accurate way. For example, when showing an animation, you might want to keep the frame rate consistent. So, if the frame rate falls behind, you simply tell the thing displaying the frames to use a faster method (by telling it to use a new parent) of getting the frames onto the screen (e.g., half as many bits, or don't do it at all). When the time becomes available, change the parent again, back to the slow way of putting the entire frame on the screen.

Something like this (using your "panic" idea) (excuse the syntax -- consider this semi-pseudocode):

noPanicWay = (| setPosition <- aPoint |) panicWay = (| setPosition. setPosition: foo = (|| self) "Ignore the argument and don't assign" |) myPanicSafeObject = (| parent* <- noPanicWay. panic = (|| parent: panicWay ). unpanic = (|| parent: noPanicWay ) |)

Now, when you tell myPanicSafeObject to panic, it starts ignoring assignments. When you unpanic it, it starts performing assignments.

Brook