Re: Function overloading for ObjC classes
Re: Function overloading for ObjC classes
- Subject: Re: Function overloading for ObjC classes
- From: Glen Low <email@hidden>
- Date: Mon, 23 Feb 2004 07:46:52 +0800
Allan, Ondra, All:
On 22. Feb 2004, at 11:53, Ondra Cada wrote:
Uh-oh. There are three things:
[...]
None of the three has anything to do with overloading.
So what are you saying? that none of the three introduce a static type
for use in overloading? as stated, it does work if only I use @class --
it also works for types which are not as closely related, i.e. I can
make an NSString overload and an NSData overload.
Allan: Would that be in ObjC++ code?
(since it is based on the compile-time type information, and thus
could and would bring ugly inconsistencies at runtime
To avoid run-time errors with Cocoa you would have to fill your code
with isKindOf: assertions, even without function overloading.
Allan: I think overuse of isKindOf: is a bit of hangover from
pre-generic C++/Java thinking. I prefer to use informal protocols and
performsSelector: which is more granular. E.g. most of the AppKit
classes with delegates seem to use performsSelector: to check if the
delegate implements some functionality, rather than isKindOf: to see if
it conforms to a formal protocol.
Whenever I use formal protocols or in my C# programming, interfaces, I
tend to make them as small as possible, and with methods that must go
together.
In C++ or Java the overloading is just a poor man's replacement for
categories (and in C++ also lack of instanceof, although that is to be
used only in emergencies ;)
C++ has both typeid, dynamic_cast and RTTI (run-time type information)
-- but function overloading does serve many useful purposes -- mostly
related to generic programming, something absent from Cocoa, despite
its OO features ;)
Ondra: I don't see how ObjC categories are a replacement for
overloading, perhaps I'm missing something. Can you define a method
with the same name in two different categories on the same class,
without the runtime being confused? If you're talking about the
(runtime) addition of functionality to a class, this is a unique ObjC
feature that seems to have a different use than C++/Java overloading.
Allan: There is an often unnoticed convergence between ObjC runtime
typing and C++ generics. Both seem to value actual class functionality
and informal protocols vs. large inheritance hierarchies and formal
protocols. In ObjC you can send arbitrary messages to id, in C++ you
can send arbitrary messages to a template parameter. The difference is
that ObjC checks at runtime and C++ checks at compile time (template
instantiation time), but the consequences of either are not as severe
as running an arbitrary function on void* in C.
I suspect the reason why function (and method) overloading isn't in
ObjC are:
1. No operator overloading. The best use of function/method overloading
IMHO. If you can't change the definition of +, you've removed 60% of
the reason for function overloading.
2. Being able to "name" parameters. E.g. initWithClassA: (A*) a classB:
(B*) b; means you can simply change the name to get a method
"overload": initWithClassA: (A) a classC: (C) c; -- not possible with
C++ and Java which have no named parameters.
3. ObjC inherits C's lack of function overloading.
Another way of looking at 2. is that in ObjC the method signature (to
select the unique function) is transparent to the programmer:
initWithClassA:classB: OR initWithClassA:classC: . In C++ (and
presumably Java), the method signature needs to involve the static type
of the parameters: init (A*, B*) OR init (A*, C*).
Cheers, Glen Low
---
pixelglow software | simply brilliant stuff
www.pixelglow.com
_______________________________________________
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.