Re: Extending KVO to scalar struct types?
Re: Extending KVO to scalar struct types?
- Subject: Re: Extending KVO to scalar struct types?
- From: Ken Thomases <email@hidden>
- Date: Thu, 28 Aug 2014 22:52:18 -0500
On Aug 28, 2014, at 10:25 PM, Graham Cox <email@hidden> wrote:
> I had an idea that could simplify quite a bit of tedious glue code, but I'm not sure if it's feasible.
>
> -[NSObject setValue: forKeyPath:] can take a key path for any property, but not for fields of that property if it's a scalar struct type, e.g. @"myObject.location.x" isn't allowed if the 'location' property is NSPoint for example, because NSPoint isn't an object.
>
> I was wondering if I could figure out a way to make this work as a pre-processing step prior to setting the value. So for example, knowing that I want to set a field of a struct property, I could call a special method that strips off the last part of the key path, uses the remainder to get the current scalar value, and then use the last part of the path to mutate the relevant struct field prior to setting it back, again just using the remainder of the keyPath.
>
> The problem here is being able to get to the struct's field at runtime given its name as a string. Is that even possible? If it is my scheme should work, otherwise it's back to the drawing board.
>
> Incidentally am I right in thinking that bindings is able to do this?
Bindings it not able to do this in most cases.
In case you're not aware, certain Core Animation classes have support for this sort of thing: Core Animation Programming Guide: Key-Value Coding Extensions – Key Path Support for Structures.
<https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreAnimation_guide/Key-ValueCodingExtensions/Key-ValueCodingExtensions.html#//apple_ref/doc/uid/TP40004514-CH12-SW8>
I suspect they use type encoding to interrogate the type of the property (via its getter or setter signature, as appropriate) and then support field access for certain specific structure types they understand.
I don't know if there's a general way to do it.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden