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: Bill Bumgarner <email@hidden>
- Date: Tue, 19 Jun 2007 11:40:59 -0700
A brief followup...
I understood why 'id' exists, but was curious about its history.
Conveniently, Steve Naroff -- one of the original caretakers of
Objective-C -- sits a couple of doors down, so I asked.
From the developer's perspective, Objective-C is generally treated
as a singly rooted language. That is, you generally work with only
one root class. For Cocoa, that class is NSObject. NSProxy shows
up, too, but generally acts as a mostly transparent proxy to some
instance of a class rooted at NSObject, be it local or remote.
There are other root classes. Originally, the most common root
class was Object. It still exists on Mac OS X, if you look hard
enough. As well, David Stes' Portable Object Compiler (http://
users.pandora.be/stes/compiler.html) compiles to the Object based
class hierarchy.
And, of course, you are free to create your own root classes.
So 'id' is -- as someone previously said -- effectively a (void *)
for object types. A variable of type 'id' may possibly respond to
any random method the compiler knows about.
Type casting to something more specific allows the compiler to
greatly constrain the set of methods that might be possible and,
thus, provide much better validation that you are calling the object
correctly.
---
Even with the general notion that Objective-C is a singly rooted
language and with the relative pervasiveness of the NSObject class,
it still makes sense to have the 'id' type for a handful of
reasons. Most significantly:
* it is a means of indicating that you do, in fact, not care one
little bit what type of an object the id refers to. For example:
- (IBAction) copy: (id) sender;
This indicates that "sender" is completely irrelevant. And it is.
A 'copy' operation is very well defined, completely generic, and not
something that you want to behave differently based on sender -- use
"Copy as HTML..." and a different action method for clarity, please!
So, in this case, (id) means less clutter in the code and more
explicit intent.
* it supports fully dynamic programming models, including the ability
to define new root classes. An 'id' guarantees that you can
introspect the class/instance using the C based API at the core of
the runtime. It allows the creation of such code without requiring
potentially dangerous ( void* -> object* ) or goofy (NSObject* ->
MyRootClass*) casts. Clearly, not something you would do with any
frequency, but a very powerful and handy capability in those rare
cases where it is needed. Not that the <NSObject> protocol allows
you to declare that your root class will play nicely with NSObjects
(mostly) and provides a specification for doing so.
---
Now, with all that said, (id) is something to be avoided unless you
really, really need it. Declaring that a particular variable is a
reference to an instance of a specific class or subclass enables the
compiler to help you write correct code.
b.bum
_______________________________________________
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