@Matt: But in theory my example should work, if "object" is an objective-c object, "this" is a property of "object", "that" is an ivar of "this", "something" is a property of "that", and "somethingElse" is an ivar of "something".
It might work, but I wouldn't assume it does. From an implementation perspective, I think it would be more manageable to disallow statements which mix properties, structs, pointers to structs and so on. That could be a real mess for both the compiler and anyone who has to read that code.
Objective-c already has a great way of accessing object data where nesssary, accessors make code more readable, and in the event that you need to access a path you can just use: [object valueForKeyPath:@"..."].
I actually think that's too verbose for today's purposes, and it can be somewhat expensive to parse the keypath string. Properties are implemented at the compiler level with a low-propfile syntax. I think it's an improvement overall.
by Scott Stevenson — Jan 01
It might work, but I wouldn't assume it does. From an implementation perspective, I think it would be more manageable to disallow statements which mix properties, structs, pointers to structs and so on. That could be a real mess for both the compiler and anyone who has to read that code.
Objective-c already has a great way of accessing object data where nesssary, accessors make code more readable, and in the event that you need to access a path you can just use: [object valueForKeyPath:@"..."].
I actually think that's too verbose for today's purposes, and it can be somewhat expensive to parse the keypath string. Properties are implemented at the compiler level with a low-propfile syntax. I think it's an improvement overall.