--- [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/