4 ms·

Yeah, 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 i

Yeah, 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"); This expands into variable declarations and type-checked initialisations from objectForKey: method calls which otherwise are very messy. You could define something similar for extracting and binding from NSValues in one step, though none of this is very elegant.

tolmasky 14y ago
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: void * p; int x = p; It will get angry, it knows p is a pointer and you want an int. Couple this with Xcode also knowing whether something is just id or actually an NSValue, and you can then do this: id something = [object returnIdSoYouDontWhatItReallyIs]; int somethingAsInt = something; // error, something can't be converted to int However, here it should be fine: NSValue * something = [object returnsSomethingMysterious]; int somethingAsInt = something; // OK, replace with something.intValue Of course, you'd probably want some sort of explicit unboxing operator (to match the explicit boxing operator @()), because sometimes you do want to do crazy things like cast a id to an int. Maybe something like: @^()

tolmasky 14y ago

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: void * p; int x = p; It will get angry, it knows p is a pointer and you want an int. Couple this with Xcode also knowing whether something is just id or actually an NSValue, and you can then do this: id something = [object returnIdSoYouDontWhatItReallyIs]; int somethingAsInt = something; // error, something can't be converted to int However, here it should be fine: NSValue * something = [object returnsSomethingMysterious]; int somethingAsInt = something; // OK, replace with something.intValue Of course, you'd probably want some sort of explicit unboxing operator (to match the explicit boxing operator @()), because sometimes you do want to do crazy things like cast a id to an int. Maybe something like: @^()