pbiron@weber.ucsd.edu (Paul Biron) (10/16/90)
I'm trying to figure out an "elegent" way to keep a sub-class
from inheriting methods from its super-class. In this case,
I'm making a Stack class out of the List class. Since a
Stack should specifically deny "random" access to its elements,
I need a way to keep it from inheriting ObjectAt:, etc.
So far, all I've done is defined these kinds of methods like:
- ObjectAt:(int)num
{
fputs ("Stack does not recognize selector ObjectAt:\n", stderr) ;
kill (getpid (), SIGIO) ;
}
In other words, just give the same kind of message that the
Obj-C runtime mechanism gives when you send an unknown message
to an object.
Is there a "better" way? Is there anything in the specs for
Obj-C which say how this should be handled (I couldn't find
it, if it is there).
Paul Biron pbiron@ucsd.edu (619) 534-5758
Central University Library, Mail Code C-075-R
Social Sciences DataBase Project
University of California, San Diego, La Jolla, Ca. 92093lerman@stpstn.UUCP (Ken Lerman) (10/16/90)
In article <3861@network.ucsd.edu> pbiron@weber.ucsd.edu (Paul Biron) writes:
->
->I'm trying to figure out an "elegent" way to keep a sub-class
->from inheriting methods from its super-class. In this case,
->I'm making a Stack class out of the List class. Since a
->Stack should specifically deny "random" access to its elements,
->I need a way to keep it from inheriting ObjectAt:, etc.
->
->So far, all I've done is defined these kinds of methods like:
->
->- ObjectAt:(int)num
->{
-> fputs ("Stack does not recognize selector ObjectAt:\n", stderr) ;
-> kill (getpid (), SIGIO) ;
->}
->
[...]
->Paul Biron pbiron@ucsd.edu (619) 534-5758
->Central University Library, Mail Code C-075-R
->Social Sciences DataBase Project
->University of California, San Diego, La Jolla, Ca. 92093
At Stepstone, we write:
return [self shouldNotImplement:_cmd from:Object];
or:
return [self notImplemented:_cmd];
depending on the situation.
In this matter, I write only for myself; not for Stepstone.
Kenpbiron@weber.ucsd.edu (Paul Biron) (10/17/90)
In <3861@network.ucsd.edu>, pbiron@weber.ucsd.edu (Paul Biron) writes: >I'm trying to figure out an "elegent" way to keep a sub-class >from inheriting methods from its super-class. [feable attempt deleted] >In other words, just give the same kind of message that the >Obj-C runtime mechanism gives when you send an unknown message >to an object. >Is there a "better" way? Is there anything in the specs for >Obj-C which say how this should be handled (I couldn't find ^^^^^^^^^^^^^^ see below Thanx to those who responded to my posting. Here is the answer. The Object class defines a method -doesNotRecognize:(SEL)aSelector which does just what I want. So to prevent a sub-class from inheriting a method from its super-class just re-define it as: - someMethod:arg { [self doesNotRecognize:@(someMethod:)] ; return (self) ; } The reason for my not being able to find this in the NeXT on-line manuals is that the description given for this method says (Chap 22, p 31): - doesNotRecognize:(SEL)aSelector Prints an error message. The Objective-C run-time system sends doesNotRecognize: messages whenever an object recieves an _aSelector_ message that it can't respond to. You generally wouldn't send them in the code you write. Again, I have to bitch about NeXT documentation (or maybe this Spec Sheet comes straight from StepStone, even though it does have NeXT specific things in it?). Upon first purusal of the Spec Sheet, I read "the run-time system sends" and "you wouldn't send", so I just skipped over it, thinking that it didn't apply. Not only that, but it doesn't mention that a SIGIOT is generated! Thanx again to those who pointed me at this. Paul Biron pbiron@ucsd.edu (619) 534-5758 Central University Library, Mail Code C-075-R Social Sciences DataBase Project University of California, San Diego, La Jolla, Ca. 92093