Xcode 4.4 adds support for Obj-C literals(itunes.apple.com)
itunes.apple.com
Xcode 4.4 adds support for Obj-C literals
http://itunes.apple.com/gb/app/xcode/id497799835?mt=12
15 comments
Also see this guide how to use subscripting in Xcode 4.4 http://petersteinberger.com/blog/2012/using-subscripting-wit...
Is it possible to downgrade back to 4.4? 4.4.1 seems to crash often now when stepping through my code.
See http://clang.llvm.org/docs/ObjectiveCLiterals.html for more information, but some examples from that page:
PS: Not sure if the object subscripting stuff is supported yet, but that looks awesome too!
NSNumber *fortyTwo = @42; // equivalent to [NSNumber numberWithInt:42]
NSNumber *piDouble = @3.1415926535; // equivalent to [NSNumber numberWithDouble:3.1415926535]
NSNumber *yesNumber = @YES; // equivalent to [NSNumber numberWithBool:YES]
NSArray *array = @[ @"Hello", NSApp, [NSNumber numberWithInt:42] ];
NSDictionary *dictionary = @{
@"name" : NSUserName(),
@"date" : [NSDate date],
@"processInfo" : [NSProcessInfo processInfo]
};
PS: Not sure if the object subscripting stuff is supported yet, but that looks awesome too!
Note that if you have
int foo = 42;
NSNumber* boxed = @foo; // fails
NSNumber* boxed = @(foo); // works
#define BOXED(val) ({ typeof(val) _tmp_val = (val); [NSValue valueWithBytes:&(_tmp_val) objCType:@encode(typeof(val))]; })
CGRect rect = {{ 0, 0 }, {100,200}};
NSValue* boxed = BOXED(rect);I've made that same macro, unfortunately the unboxing is the hard part because you don't know what type the NSValue contains. This is why I was hoping it would be a compiler feature because the compiler could use the surrounding info to figure it out:
int x = some_nsvalue; // it knows you want an int
[obj takeDouble:some_nsvalue]; // it knows takeDouble expects a double
(CGAffineTransform)some_nsvalue // typecast is the ultimate hintYeah, that would require type inference via the expression/return value though and not even C++ can do that (by and large anyway). But then ObjC as a language in general doesn't seem to care much for type safety anyway. I realise this makes objects quite flexible, but at the same time it's so, so easy to write code with undefined behaviour or with glaring security issues. I've actually come up with a typed variable binding macro for picking apart untrusted NSDictionaries (primarily from untrusted plists), which when used looks something like this:
SSDC_BIND_DICTIONARY_TYPED(result,
NSArray, errors, @"errors",
NSArray, warnings, @"warnings",
NSNumber, new_volume, @"volume-new",
NSString, volume_name, @"volume-name",
NSString, volume_type, @"volume-type",
NSDictionary, fs_size, @"filesystem-size",
NSDictionary, host, @"host",
NSDictionary, cache, @"cache",
NSArray, unmount_required, @"unmount-required",
NSArray, unmount_recommended, @"unmount-recommended");
So a number of things. With LLVM, Objective-C has become way stricter and picky about types. To get away with calling a random method on an object ObjC knows doesn't have it, you have to explicitly cast it. This was necessary to ensure ARC would work correctly. Although, yeah, in the dictionary example it just returns an id so its up to you to type it correctly.
That being said, that doesn't have much to do with what I'm talking about because here I'm referring specifically to NSValue -> primitive type conversion. Just about every compiler is super picky about this. Try doing this in Xcode:
That being said, that doesn't have much to do with what I'm talking about because here I'm referring specifically to NSValue -> primitive type conversion. Just about every compiler is super picky about this. Try doing this in Xcode:
void * p;
int x = p;
id something = [object returnIdSoYouDontWhatItReallyIs];
int somethingAsInt = something; // error, something can't be converted to int
NSValue * something = [object returnsSomethingMysterious];
int somethingAsInt = something; // OK, replace with something.intValue
Subscripting only on OS X not iOS.
You can use them on iOS 5.1 by implementing the methods the subscripts map to on NSArray and NSDictionary (as well as mutable) in categories.
For NSArray:
For NSArray:
- (id)objectAtIndexedSubscript:(NSUInteger)index {
return [self objectAtIndex:index];
}
- (void)setObject:(id)object atIndexedSubscript:(NSUInteger)index {
if (index < self.count){
if (object)
[self replaceObjectAtIndex:index withObject:object];
else
[self removeObjectAtIndex:index];
} else {
[self addObject:object];
}
}
- (id)objectForKeyedSubscript:(id)key {
return [self objectForKey:key];
}
- (void)setObject:(id)object forKeyedSubscript:(id)key {
[self setObject:object forKey:key];
}The implementation already exists in iOS 5, you just need to make the compiler happy; a header that declares them is sufficient.
Is it just as easy as creating categories that add these methods?
The functionality is present for iOS, it just isn't being exposed. If you create a category header file (just header, not implementation) the compiler'll pick up on it and all will work fine.
This isn't my code, but I've been happily using it for a week or so now: https://gist.github.com/3299750
This isn't my code, but I've been happily using it for a week or so now: https://gist.github.com/3299750
Apparently OSX 10.8 and iOS 6 bring support for subscripting to native NSArray/NSDictionary, but I think you can add subscripts to your own classes already just by implementing the following methods:
-(id)objectAtIndexedSubscript:(NSUInteger)index;
-(void)setObject:(id)object atIndexedSubscript:(NSUInteger)index;
That functionality is coming with Xcode 4.5