--- [EMAIL PROTECTED] wrote:
> > Are you speaking in terms of limitation, or requirement?
> > It would be nice to have a syntax solution. I've seen p5 interfaces
> > with stubs that die so that you have to override them in a
> > subclass. It works, but seems a little kludgy.
>
> Back in 1988 programming Objective-C under NeXTSTEP you could have a
> class that does these things (based on methods inherited from
> Object):
> - iJustCantSeemToGetAnythingDone {
> [self notImplemented:_cmd]; // TODO: We'd better write this soon!
> }
> - imFeelingAbstract {
> [self subclassResponsibility:_cmd];
> }
> - bogus {
> [self error:"Bogon flux exceeds limit %d\n", BOGON_LIMIT];
> }
As in the p5 equivs (???):
sub iJustCantSeemToGetAnythingDone {
shift->notImplemented(@_); # better write this soon!
}
sub imFeelingAbstract {
shift->{subclassResponsibility}->(@_);
}
sub bogus {
dir sprintf "Bogon flux exceeds limit %d\n", BOGON_LIMIT;
}
or am I completely off base?
(never done Objective-C under NeXTSTEP).
I think I may have missed the point.
Sorry, feeling dense. :)
> Also, there was a doesNotRecognize: method that was called by the
> runtime system when method lookup failed. I presume you could
override
> it to do nasty things, but I never did that myself.
AUTOLOAD()? Oh, I *have* done nasty things with that, that I don't even
like to talk about....
Mostly, though, I just use it to fake up quick templated accessors.
If I know there are forty fields on an object that are all going to
look exactly alike, I'll stick a build-on-the-fly routine in AUTOLOAD
so that if one gets called it has a legitimate accessor the next time.
That way I only have to write one reasonably abstracted routine, rather
than the forty cut-paste-edit versions I've seen folk actually do in
this shop....
"Hey, it was quick and easy...."
Ugh.
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
