Re: KVC and Core Foundation types
Re: KVC and Core Foundation types
- Subject: Re: KVC and Core Foundation types
- From: Graham Cox <email@hidden>
- Date: Fri, 01 Feb 2013 21:21:01 +1100
On 01/02/2013, at 6:16 PM, Quincey Morris <email@hidden> wrote:
> On Jan 31, 2013, at 22:54 , Graham Cox <email@hidden> wrote:
>
>> For the errant CFTypes, I hit -valueForUndefinedKey: and -setValue:forUndefinedKey:, overridden in this base class. This then checks whether in fact the selector really is undefined, and if not, it forces the value to be returned using -performSelector. It then passes off these CFTypes to some conversion utilities that, for each type of interest, grabs all the necessary values and puts them into a dictionary, and returns that. The dictionary of course can be archived. On dearchiving, I simply reverse the process, building new CFType objects from the dictionaries.
>
> This sounds potentially ugly, unless you left out some of the details. You can't simply check whether the selector is defined, since this will go terribly wrong if the property type is a genuine non-object that's not one of the scalars that KVC converts automatically. E.g. CGRect on the Mac.
Well, I agree that aspect of it needs to be more robust but I'm not clear how to go about type checking here. I can't call [objCType] on the return value because it's not implemented, and I can't use @encode() because it's not a type name... there's method_copyReturnType() but it's not clear whether it's appropriate. Bit stuck there.
Since this will only occur for when -valueForUndefinedKey: is hit, it only applies to the cases where a) it's a CFType, b) it's a typo in the key name, but that's a programming error anyway (and such a selector doesn't exist, so checking the selector is sufficient), or c) as you state, for other unsupported scalar types. But what are these? You mention CGRect but in the 64-bit runtime that's the same as a NSRect, and as far as I can see it's supported just fine - I return CGRect quite often.
> Second, you're kinda exposing the CFType'ed properties to *all* KVC use as objects, not just for archiving/unarchiving purposes. Don't be surprised if this bites you in the behind 6 months from now.
Mmm, well, sort of. I have made sure I've left myself comments to remind myself of it, but again, this isn't the issue you might think. If I leave the standard implementation in place, and I use KVC at any stage to access these CFType properties, I'll get an exception (under the old regime) or some sort of object (under the new one), but in either case I would have to know what I'm expecting to use KVC at all (and expecting an exception is not really useful to anyone). At least this way KVC works for these properties, though not in a way compatible with. e.g. bindings. I'm not using bindings. But returning some sort of object is still useful in other cases, for example observing property changes with KVO. I just need to make sure I know what the observer is going to get. At this stage it's a bit theoretical, as I'm not doing any of that.
>> Those objects that can take advantage of this inherit from a simple base class which exports one public class method, +archivableProperties, returning a NSSet of keys. By doing this rather than using runtime introspection to find all the properties allows objects to only specify those that they want to auto-archive, and others can be ignored or handled as a special case if needed. Then, this same base class implements default -initWithCoder and encodeWithCoder: methods that iterate these keys using KVC to get and set the property values.
>
> My idea was not that you'd use the runtime to *find* the properties. Rather, you'd get an array of them the way you originally intended, but check the property type before invoking the KVC methods, and in the CFType cases do the conversion without involving any KVC methods. That would avoid problems like the ones outlined above.
>
Well, I might pursue this line of thought if I had a clear understanding of how to reliably check the type of an arbitrary property.
--Graham
_______________________________________________
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