• 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: Interface Builder Outlets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interface Builder Outlets


  • Subject: Re: Interface Builder Outlets
  • From: Derrick Bass <email@hidden>
  • Date: Fri, 16 Dec 2005 07:41:37 -0600


On Dec 16, 2005, at 6:53 AM, Ondra Cada wrote:

J o a r,

On 16.12.2005, at 8:38, j o a r wrote:



I think that one of the advantages of Cocoa+ObjC is that you rarely ever really have to care about pointers - you can think of it as dealing with objects



Personally, I feel the distinction betwixt pointers to objects and objects themselves is *very* important. There are people with some C ++ background, and you can have object variables there: that may get confusing.

Especially for someone with good background in plain C, in my personal opinion, it is worth to say (which, to be fair, the docs do pretty well):

(a) any "object variable" is in fact a pointer to an object (which itself is a memory chunk);
(b) an "outlet" is a normal object variable; we just by convention call it "outlet" if its contents is to be set up from an NIB;
(c) there's a special identifier "IBOutlet", which is ignored by compiler (just #define'd to nothing), but allows Interface Builder to recognise its outlets.

I agree. Maybe it's just me, but I find it immensely helpful to understand what is actually going on under the hood. When I started with Cocoa, it was endlessly frustrating to me not to actually know where all the objects in a nib actually came from and what IBOutlets really were. (I don't think the docs actually explain this all that well; or maybe it's just that the docs that do explain it well are hard to find; all I know is that it was several weeks before I stumbled on facts (b) and (c).)

I think (a) is important to know because of the fact that Cocoa objects are always passed by reference. If you think of, say, an NSString* as an object, that would imply that it is independent of every other NSString* in a program. But of course, it is not. The NSString object exists "out there" in memory somewhere and the NSString* simply tells me where to find it. When I pass an NSString* to a method, or store it in an instance variable, I'm telling it where to find the very same object, and not creating a new object. (Aside; this is why it makes me nuts that id is not id*.)

It's true that you usually don't need to think about the fact that an outlet is just another pointer, or that objects are really pointers. But for me, the reason I usually don't have to think about is exactly because in the past I DID think about it very hard and understood (well, mostly) what was going on under the hood. (For me, the rules surrounding when to retain and when when not to and when to release were an even better example; I just couldn't remember them at all until I actually understood the details of reference counting).

Derrick

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Interface Builder Outlets (From: Jonathan Faulkenberry <email@hidden>)
 >Re: Interface Builder Outlets (From: John Pannell <email@hidden>)
 >Re: Interface Builder Outlets (From: Boyd Collier <email@hidden>)
 >Re: Interface Builder Outlets (From: j o a r <email@hidden>)
 >Re: Interface Builder Outlets (From: Ondra Cada <email@hidden>)

  • Prev by Date: Re: Updating System Menu bar
  • Next by Date: Set of controls offered in IB palette
  • Previous by thread: Re: Interface Builder Outlets
  • Next by thread: Crash in CFStringHash - can I do anything about this?
  • Index(es):
    • Date
    • Thread