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: Andy Lee <email@hidden>
- Date: Thu, 10 Jun 2004 12:09:19 -0400
On Jun 10, 2004, at 6:43 AM, Allan Odgaard wrote:
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. ;)
Point taken, and I can see why you'd want that, but I can also see why
you wouldn't. I actually think a mathematical function is a bad
example, because there might be cases where you'd want to be conscious
of how much precision you're using, both as you're typing the code and
later as you or someone else reads it. I wouldn't mind always being
forced to be explicit about which version of sin() I meant to use if it
means one less subtle bug being caught at compile time. It's hard
enough finding bugs where values at *run time* aren't of the type you
thought they were.
This is basically the same as the longstanding debate about operator
overloading. I don't mean to have that debate again. I was just
hoping to slightly soften the original poster's negative reaction to
Objective-C syntax.
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'.
I'm not sure if this example illustrates your point, since it's not
really about generic code. Any given branch of code can only use one
of your versions of is_word_char(). The choice is deterministic and
will be made at compile time. A new version of is_word_char() won't
get used unless you add a branch in your word-counting code that uses
it. So you end up with N branches of code that all use the identifier
"is_word_char" to mean different things. The question is whether you
want the person writing the code to be explicit about which version he
or she meant to use in each branch. In general, I do when I'm reading
the code and I don't mind when I'm writing the code, but that's me.
My idea of generic code would be if each character was an object with
an isWordChar method. Your word-counting logic would call [aChar
isWordChar] and would not have to change if you later add new types of
character in the form of subclasses like MyUnicharClass or
MyWCharTClass.
--Andy
_______________________________________________
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.