• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why the need for the id type?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why the need for the id type?


  • Subject: Re: Why the need for the id type?
  • From: Rich Wardwell <email@hidden>
  • Date: Wed, 20 Jun 2007 15:59:57 -0500



On Jun 19, 2007, at 1:01 PM, Chris Williams wrote:

A key difference between the strict compile-time typing in the Visual
C++/.NET world vs. dynamic run-time typing of the Obj-C/Cocoa world is
performance. Every method invocation in the former is known and can be
optimized (even unrolled) at compile/link time, where dynamic calls like the
one posed by the OP involve trolling up the hierarchy at run-time in the
latter case. The performance difference can be significant.



This is actually incorrect in regards to .NET and Java (I know you say that is possible in .NET later in the next paragraph, but I thought this topic is worth expounding further). You most definitely do have dynamic binding at runtime. The class doesn't even need to exist at compile / link-time. The difference, which I think is the heart of this whole thread, is that you must cast or pre-agree on the interface at compile time - even if the actual class type / implementation is unknown at compile time. In this way, I can implement 40 different plug-in classes for an already compiled implementation and use them at run-time. Something that is done in Java all the time and is integral to the language.


With ObjC, I can fire and forget at compile & runtime without even having a contractual agreement on interface.

This is pretty cool... and does have performance benefits... and is a level of dynamicity that exceeds Java and .NET. But Java and .NET definitely do have a level of dynamic ability that allows for the dynamic instantiation and invocation of classes & methods with no previous knowledge other than understanding a predetermined interface.

Not trying to devolve into language study here... but I think this is very key and intertwined in the answer to the original question. An NSObject is much like Object in Java. id is a lower level construct that doesn't require any type checking. id reveals the fact that I don't need any interface or contract to make calls -- hence the concept of messages vs the more contractual method calls...

At least, that's my take... I'm fairly new to ObjC and Cocoa as well, and have found this facet of the language to be quite intriguing.

Rich

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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

  • Follow-Ups:
    • Re: Why the need for the id type?
      • From: Chris Williams <email@hidden>
References: 
 >Re: Why the need for the id type? (From: Chris Williams <email@hidden>)

  • Prev by Date: Re: Version nib loading?
  • Next by Date: Re: placing documentview at top of larger nsscrollview
  • Previous by thread: Re: Why the need for the id type?
  • Next by thread: Re: Why the need for the id type?
  • Index(es):
    • Date
    • Thread