Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Objective-C literals for NSDictionary, NSArray, and NSNumber

cocoaheads.tumblr.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#41

Post by mikeash »

demallien wrote: post #12
flyosity wrote: post #8

Earlier quoted context omitted.

Maybe I'm misunderstanding, but how much effort are you talking about here? Skipping @synthesize on properties or using literal syntax where/when it makes sense wouldn't cause much additional cognitive load and you don't have to convert old code to use the new sugar.

It's not as simple as that when you're planning for the long term. Firstly you need to examine the changes and make sure that they aren't going to create any compatability problems, of the type "if you activate this option, then you can no longer link to libraries that don't use this option". Garbage collection in particular had a lot of those sorts of problems. But even if you can convince yourself that it is just s…

This particular change takes about fifteen minutes to fully understand. Adopting does not require changing any existing code. I can kind of see where you're coming from in general, but attaching the complaint to this feature makes no sense to me. This stuff is pretty much pure win and no effort.

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#42

Post by natesm »

Zev wrote: post #39
frou_dh wrote: post #34

Earlier quoted context omitted.

Is it possible to see this straight C translation? Using Clang for example. I'm sort of aware of the "objc_msgSend" business, but would like to see more. Talking of OpenStep, after seeing some of those NeXT videos on HN the other day, I found a torrent of OpenStep 4.2 incl the dev tools. It's a VMware image and boots and runs just fine. Pretty nifty. Then I noticed OpenStep 5.0 redirects to Mac OS X on Wikipedia!

Quick example of calling a method that doesn't take any arguments and returns an object: id foo = [self bar]; is the same as: id foo = self.bar; which is also the same as: id foo = [self performSelector:@selector(bar)]; or: IMP barImp = [self methodForSelector:@selector(bar)]; id foo = barImp(self, @selector(bar); [1] and finally: id foo = ((id)(id, SEL)objc_msgSend)(self, @selector(bar)); [2, 3, 4] 1. Because we're…

Those first two and following aren't equivalent, are they? Wouldn't they compile, respectively, to:

    objc_msgSend(self, @selector(bar));
And:

    objc_msgSend(self, @selector(performSelector:), @selector(bar));

?

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#43

Post by mikeash »

frou_dh wrote: post #34
thought_alarm wrote: post #33

Earlier quoted context omitted.

Obj-C is essentially a preprocessor on top of a C compiler. Whether that C compiler is C89, C99, or C++11 is up to you. Obj-C also includes the Foundation classes that were originally introduced with the OpenStep SDK in 1994 (NSObject, NSString, NSNumber, NSArray, NSRunLoop, NSAutoreleasePool, etc.).

Is it possible to see this straight C translation? Using Clang for example. I'm sort of aware of the "objc_msgSend" business, but would like to see more. Talking of OpenStep, after seeing some of those NeXT videos on HN the other day, I found a torrent of OpenStep 4.2 incl the dev tools. It's a VMware image and boots and runs just fine. Pretty nifty. Then I noticed OpenStep 5.0 redirects to Mac OS X on Wikipedia!

Check out clang's -rewrite-objc option. It outputs C++, not C, and isn't entirely truthful since Obective-C is compiled directly these days, but should give you what you're after.

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#44

Post by mayoff »

openbear wrote: post #29

I'm glad to see these additions, but the syntax for an NSArray literal bugs me. When I want an array literal in C, I'd write ... int foo[] = { 1, 2, 3, 4, 5}; ... but in Objective-C, for an NSArray literal I'd write ... NSArray *bar = @[o1, o2, o3]; Why did they choose '[' over '{'? Oddly enough, NSDictionary uses '{'. I feel like the syntax for an NSString literal is more natural (as a C developer). NSString *baz =…

Perhaps they choose @[ for arrays because it requires less lookahead than figuring out whether @{ is the start of a dictionary or an array.

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#45

Post by marcins »

rbrown46 wrote: post #28
pooriaazimi wrote: post #17

Earlier quoted context omitted.

> ...so it only is available to those in Apple's Developer Program. correction: Apple's Mac developer program. I'm an iOS developer and I don't see Xcode 4.4 in my dashboard.

This is the second time (to my knowledge, may have been going on for a while) that an Xcode beta has been made available to only one of the two (Mac and iOS) developer programs. The Xcode 4.3 beta was only available to iOS developers -- despite containing bug fixes and improvements useful to developers on both platforms. Now the Xcode 4.4 beta is only available to Mac developers. I really don't see the logic in withh…

You can't use the beta Xcode / SDKs to build apps for the relevant App Store anyway, so while it contains neat new features it's technically only useful for developers developing that particular pre-release OS (whether iOS 5.1 or OS X 10.8).

Interestingly now Xcode 4.3 is out of beta the iOS 5.1 SDK is still only available with Xcode 4.3 DP3 (although realistically there's not much public new stuff in iOS 5.1 since presumably it's all under wraps for the iPad 3).

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#46

Post by boucher »

We've been talking about similar changes to Objective-J for quite some time (we already have JavaScript literals that map more cleanly than C ones). The one thing we've discussed that I don't think made it here is a set literal. It would be nice to have sets treated in a more first class way, considering how often arrays are used when sets would be more appropriate.

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#47

Post by yuhao »

glhaynes wrote: post #26
cageface wrote: post #11

The excessively verbose collection syntax is my #1 pain point with Obj-C. Looking forward to kicking the tires on this one.

It's never before fully struck me how cleanly the "Objective-C is too verbose" complaint really breaks down to two separate issues: one of them being that method names are long (which is arguably a plus) and the other being mostly comprised of the stuff that's apparently mostly taken care of with this release. Actually, I suppose there used to be a third, too: (auto)release/retain statements all over the place. As so…

ARC in XCode 4.2 takes care of the release/retain business!

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#48

Post by DrJokepu »

drpancake wrote: post #21
pornel wrote: post #19

Earlier quoted context omitted.

You can use C99 struct literals: return (struct x){a,b}; Small structs may be passed in registers. http://stackoverflow.com/a/3355560/27009

IIRC passing Obj-C object pointers in C structs is disallowed or discouraged by ARC.

You have to explicitly bridge them in or out of ARC and indicate the ownership rules. Sometimes, for example when you're interfacing straight C code, you have no other option.

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#49

Post by icodestuff »

openbear wrote: post #29

I'm glad to see these additions, but the syntax for an NSArray literal bugs me. When I want an array literal in C, I'd write ... int foo[] = { 1, 2, 3, 4, 5}; ... but in Objective-C, for an NSArray literal I'd write ... NSArray *bar = @[o1, o2, o3]; Why did they choose '[' over '{'? Oddly enough, NSDictionary uses '{'. I feel like the syntax for an NSString literal is more natural (as a C developer). NSString *baz =…

Could be in case they want to do literal NSValues later. Since {}-syntax is used in C for both array literals and struct literals, they needed to change one, and the picked the more common one. Otherwise is foo in:

id foo = @{ @2, @5 };

an NSArray containing two NSNumbers, or an NSValue containing a struct with two pointers (which happen to be NSNumber *s)?

I'd guess there were other edge cases they didn't want to deal with, so they didn't do literal NSValues for this release.

Or it could be that it's because []-style arrays are popular these days.

Or some of both; in picking which {} to change to @[], they reasoned that lots of people have experience with []-style arrays.

Re: Objective-C literals for NSDictionary, NSArray, and NSNumber

#50

Post by Zev »

natesm wrote: post #42
Zev wrote: post #39

Earlier quoted context omitted.

Quick example of calling a method that doesn't take any arguments and returns an object: id foo = [self bar]; is the same as: id foo = self.bar; which is also the same as: id foo = [self performSelector:@selector(bar)]; or: IMP barImp = [self methodForSelector:@selector(bar)]; id foo = barImp(self, @selector(bar); [1] and finally: id foo = ((id)(id, SEL)objc_msgSend)(self, @selector(bar)); [2, 3, 4] 1. Because we're…

Those first two and following aren't equivalent, are they? Wouldn't they compile, respectively, to: objc_msgSend(self, @selector(bar)); And: objc_msgSend(self, @selector(performSelector:), @selector(bar)); ?

The first two are the same, with a different syntax, yes.

They would both become:

  objc_msgSend(self, @selector(bar));
However, your examples are basically explicitly passing a message (1 and 2), vs dynamically building a message to pass (3).

For the second to work, the objc_msgCall function would really be:

  objc_msgSend(self, @selector(performSelector:), @selector(bar));
(The first example is saying to self to call the selector (method) named 'bar'. The second example is telling self to call the method 'performSelector:' with an argument of 'bar'.)

The runtime may or may not be smart enough to optimize this out. It has never been a bottleneck for me to bother looking into it, and I haven't come across anything to indicate one way or the other.

Post reply on HN