Re: newbie questions about objective-c, ruby, python, groovy and cocoa
Re: newbie questions about objective-c, ruby, python, groovy and cocoa
- Subject: Re: newbie questions about objective-c, ruby, python, groovy and cocoa
- From: Allan Odgaard <email@hidden>
- Date: Thu, 10 Jun 2004 12:43:57 +0200
On 10. Jun 2004, at 11:56, Andy Lee wrote:
Method overloading is a convenience provided by the compiler so you
don't have to think of a different name when you have two methods that
are conceptually the same but take different arguments. But in
Objective-C, when you have different arguments, the *natural* thing to
do is to name the method accordingly. I see this as a good thing
because it makes code more readable [...]
Well... I think function overloading in C++ was introduced to have
sin() and friends for both float and double, without resorting to
naming the functions sinFromFloat() and sinFromDouble() etc. ;)
There are two other cases where I use overloading, one is when writing
generic code, for example imagine the problem discussed some posts ago
about word counting, here we need to decide wether or not a character
is a word character, we could let the function always call
is_word_char() and then simply provide one version for 'char' and
another for 'unichar' -- later on we may even add one for 'wchar_t'.
The other case is to provide convenience -- imagine we allow the user
to register a callback, this callback can fail (and return false), but
rarely anyone want to make use of that feature. Rather than force
everybody to return true in their callbacks, we can provide two
versions of the register function, one taking a callback with a return
type of 'bool' and another one with 'void'. I do not feel a need to
spell out such difference in code, especially since a user-converter
could just as well have been implicitly applied to the callback
argument, in order to have it match the prototype of the register
function. I.e. the user really should just view it as one
(intelligent) function.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.