Re: Why the need for the id type?
Re: Why the need for the id type?
- Subject: Re: Why the need for the id type?
- From: Greg Titus <email@hidden>
- Date: Mon, 18 Jun 2007 14:28:22 -0700
On Jun 18, 2007, at 2:12 PM, Wagner Truppel wrote:
On Jun 18, 2007, at 1:46 PM, Wagner Truppel wrote:
I don't understand why id should be necessary. Why isn't NSObject
(or some other root class) enough?
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaObjects/chapter_3_section_3.html#//
apple_ref/doc/uid/TP40002974-CH4-DontLinkElementID_130>
mmalc
Yes, I've read that before. Now, note this sentence:
"The id data type makes it possible to substitute any type of
object at runtime."
The same would be true of some actual root class, be it NSObject or
some other, as in java's Object. That's the essence of my question,
namely, that id seems to be nothing but a root class in disguise.
Wagner
The difference is in _which_ methods you can call on the object that
is an "id". This code:
NSObject *foo;
[foo someRandomMethod];
... will give me a warning at compile-time in Objective-C because the
NSObject class does not implement -someRandomMethod. In Java or in C+
+, you actually have to explicitly cast foo into some class which
responds to that message. In C++ that might cause some kind of type
conversion, who knows (without looking at the classes involved). In
Java that will cause an explicit type check operation at runtime.
In this code:
id foo;
[foo someRandomMethod];
As long as -someRandomMethod exists _anywhere_ on any class, it will
work. Importantly, -someRandomMethod can be implemented on many
classes which DO NOT share any common root class, and the code will
work.
What if I have a method like -objectEnumerator on NSArray, NSSet,
NSDictionary, which don't share a common root class other than
NSObject, which does not implement that method. In Java, you have
nothing to cast to. How would you write generic code that can
enumerate over anything enumerable?
The solution in these other languages is either some sort of meta-
programming (i.e. templates) or to add a new superclass (like a
theoretical "NSEnumerable") which gives you something in common and
something to cast to. Templates have a huge drawback in complexity,
which ought to be obvious. New superclasses also have a less obvious
drawback in multiplying the number of classes and making inheritance
hierarchies much deeper, leading to more complicated, more brittle,
less flexible class libraries.
Hope this helps,
- Greg
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden