Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

mdeh

macrumors 6502
Original poster
Jan 3, 2009
345
2
Firstly, I really want to thank all those who take the time to answer questions. Your input is invaluable, probably more than you realize. Hopefully, some day those of us who now are doing most of the asking will be able to shoulder more of the answers!

Code:
attributedStringForObjectValue:withDefaultAttributes:

"The default implementation returns nil to indicate that the formatter object does not provide an attributed string."


editingStringForObjectValue:

"The default implementation of this method invokes stringForObjectValue:"


getObjectValue:forString:errorDescription:

"The default implementation of this method raises an exception."


Ok…quick question.

Quite often, a method will carry the admonition that the "default" implementation will do this or that, usually, return nil, raise an exception etc, as the above trivial examples show.
Does this simply mean that placing the method in a ?subclass, **with no code added** will do these things? And the implication is, that those methods are "template" methods and thus need to be over-ridden?

Thanks.
 
Does this simply mean that placing the method in a ?subclass, **with no code added** will do these things? And the implication is, that those methods are "template" methods and thus need to be over-ridden?

Thanks.

Well, if you override it with an empty method, it'll do nothing. If you *don't* override it, it will do the thing it says is the default.
 
Sorry, I misread the question. The "default implementation" represents the normal behavior of the class. In cases where you see that phrase, it usually means "normally, this method does nothing useful, it is up to you to write an override to make it do something useful".

If a method is supposed to return a value and you just put in empty code, you will probably get a compiler warning (unless you have turned those off), but because of the nature of the stack, the return value will then be unpredictable.
 
Thank you Catfish Man and Sydde.

So, from both your answers, does this thus imply, if for example, the default would raise an exception, that you pretty much **have** to implement the method in the subclass...and provide suitable code to avoid this situation?
 
Thank you Catfish Man and Sydde.

So, from both your answers, does this thus imply, if for example, the default would raise an exception, that you pretty much **have** to implement the method in the subclass...and provide suitable code to avoid this situation?

Yes, although there is a special-case exception that will avoid this situation. Namely, that you don't use that method in your code. If it is never called, you should never get the exception that is in the default implementation. Of course, this is bad because later you will forget (or someone else updating the code will not know) and that method will cause a run-time exception.

Still it's not necessarily better to implement a method that does nothing just to put something there. If you aren't using that method, then later you forget you implemented nothing useful the code will run and possibly have a bug. Without an exception at run-time, it might be very hard to notice the incorrect/missing behavior.

These are just the usual perils of software development.
 
Yes, although there is a special-case exception that will avoid this situation. Namely, that you don't use that method in your code. .............

Still it's not necessarily better to implement a method that does nothing just to put something there.
These are just the usual perils of software development.

Perils? :)

To explore this a bit further, ( and possibly not understanding in it's entirety your reply), I took a method whose default implementation raised an exception, and in the subclass called [super withNameOfAboveMentionedMethod] and, as expected, raised an exception. So at least I understand how **that** works.
What I do not quite understand is **Why** or under **what** circumstances anyone would call the default implementation. Hope that makes sense?
 
In this case it's mostly there as a reminder to subclassers that they should override it, as you guessed. Some other default implementations provide "typically ok" behavior. For example if you don't override -description, it will print a generic object description with the address of your object.
 
In this case it's mostly there as a reminder to subclassers that they should override it, as you guessed. Some other default implementations provide "typically ok" behavior. For example if you don't override -description, it will print a generic object description with the address of your object.


Got it! thanks Catfish Man. So much to learn, so little time!! :D
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.