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: Wagner Truppel <email@hidden>
- Date: Tue, 19 Jun 2007 02:44:50 +0200
On 19 Jun 2007, at 02:13, Greg Titus wrote:
On Jun 18, 2007, at 3:06 PM, Wagner Truppel wrote:
Perhaps I should be a bit more specific.
Imagine that I decided to create my own language, fashioned
closely to java but with a few whistles and bells added to Object.
More specifically, any Object instance would know how to do
introspection much like NSObject, with methods to answer questions
like "does the object respond to such and such message", "what is
the object's superclass", and so on. (All of that can be done in
java, of course, but one has to deal with all the exceptions and
so on. I'm talking about a transparent process here, where the
developer need not worry about any of that.)
Of course, the compiler can issue warnings for unanswerable
messages, just as XCode's does for Obj-C. Moreover, the runtime
system associated with the language would take full advantage of
those facilities, determining at runtime whether an object can or
cannot respond to a given message. If not, the message would be
ignored.
It seems to me that I would have *all* of the behavior of
Objective-C, without id. The root class in my language would play
the role of Obj-C's id.
It's for this reason that it seems to me that id is nothing more
than a root class in disguise. Yes, I know, id is not a class (I
suppose my abuse of language in previous messages led people to
think that I was claiming id to be a class). But it might as well
be, since it behaves like a smart root class.
Okay, say you have your own language with Object as the root class.
Presumably, like in Objective-C and in Java, you'll want some
static type checking. By which I mean that if you declare that a
particular variable is a Foo, then when you send messages to that
object, you'll want to know at compile-time that the Foo class
actually implements that message. (If nothing else, this saves you
from dumb things like typos and misspellings of method names.)
Now, your root class itself will implement some methods. Like the
"does the object respond to such and such message" (in Obj-C that
would be -respondsToSelector:) for instance.
How does someone writing in your language make the distinction
between when (1) they _want_ static type-checking, so that they'll
get a warning/error if they accidently call -respondsToSeletor: on
an Object (notice the typo), versus (2) they _don't_ want static
type-checking, so that they can call any message at all on an
instance without compile-time restriction?
Languages like Java only provide the first option - always static
type checking. Languages like Smalltalk only provide the second
option - always no restriction. In Objective-C the answer is to
treat variables typed as the root class (NSObject) identically to
variables typed as any other specific class, and perform static
type checking to make sure that the NSObject actually implements
the method. When you don't want static type checking you use "id"
instead.
Since there are two different purposes there needs to be two
different types.
Does that help?
- Greg
Ahh!!! Now I get it. Thank you!
Wagner
_______________________________________________
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