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: "Kevin Hoffman" <email@hidden>
- Date: Tue, 19 Jun 2007 08:09:41 -0400
- Thread-topic: Why the need for the id type?
As a .NET developer, I'd like to interject a little something here. The
fictitious language/framework that is being proposed here sounds ...
well... exactly like the .NET Framework. What you have is a runtime, on
top of which sits a pile of common types defined in terms of the runtime
(such as integer, string, etc), and on top of that is your library of
tools (your "Cocoa" if you will...).
In .NET, there are no dynamically dispatched method calls. You can't
simply fire a method off and be done with it, hoping that at some point
during runtime the method will be added via category, class extension,
or some other wizardry. In short, when you compile your .NET code, it
does a lookup on the method name being invoked at compile time and uses
that lookup result as what shows up in the MSIL (.NET semi-equivalent of
Java bytecode). .NET handles the passing of objects that can be
"anything" using the Root Class pattern, which is manifested in the
class System.Object, from which all objects inherit.
The beauty (IMHO) of ObjC is that this isn't necessary. There is a loose
coupling between objects and the methods they support. Rather than
requiring a lookup and translation into some vtable-style dispatching at
compile and link time, you can dispatch methods dynamically. Were you to
build ObjC over again from scratch and eliminate the id type in favor of
a root class, you then add to Objective-C that which is anathema to its
existence - tight coupling of methods. The reason why the .NET
System.Object works for that framework is because it is _already_
tightly coupled, and the Root Class was the only way to accomplish
things (along with Interfaces (protocols in ObjC) and Generics (no
direct equiv in ObjC).
Anyway, long story short, I like the id type because it is part of what
allows ObjC to be what it is - a damn fine language. I like
System.Object in the .NET Framwork because it makes most of the .NET
Framework possible. One of my pet peeves is when languages become
diluted or overloaded to make them too much like other languages.
-----Original Message-----
From: cocoa-dev-bounces+khoffman=email@hidden
[mailto:cocoa-dev-bounces+khoffman=email@hidden] On
Behalf Of Wagner Truppel
Sent: Monday, June 18, 2007 8:45 PM
To: Greg Titus
Cc: Cocoa-dev List
Subject: Re: Why the need for the id type?
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:
m
This email sent to email@hidden
_______________________________________________
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