Re: blocks and id
Re: blocks and id
- Subject: Re: blocks and id
- From: Andreas Grosam <email@hidden>
- Date: Sun, 16 Dec 2012 16:50:29 +0100
On 15.12.2012, at 01:44, Uli Kusterer wrote:
>
> On 15.12.2012, at 01:38, Uli Kusterer <email@hidden> wrote:
>
>> On 12.12.2012, at 10:03, Andreas Grosam <email@hidden> wrote:
>>> How can I check at runtime whether an object (id) is actually a block, and not another kind of object?
>>
>> Not a good idea. What are you really trying to do?
(I explained this in more detail in later posts, see also below)
>> Here's a few common cases and suggestions on how to do it better, and why:
>>
>> 1) Serializing objects. Generally, the object (or a category on it if it's an object you didn't create) should implement a method that knows how to serialize/unserialize it, like -initWithCoder: and -encodeWithCoder:. This allows any class to be added, and allows for overriding a the method in a subclass. If you use -isKindOfClass:
>> , all subclasses will also return YES, and that one method will have to know about all the different types (from different layers of your app that might be serialized), and you'll have one file with thousands of dependencies, that get dragged into any other app that wants to be able to use the same serialization mechanism.
>>
>> 2) Implementing special behaviour on some objects, while falling back on some default behaviour for all others. Call respondsToSelector: in this case. It has the advantage that it doesn't break duck typing. Even if you get an NSProxy for the actual object, it will respond to the selector and still work as expected.
>
> Same for any other kind of method forwarding or dynamic method implementation like Key-Value-Observing.
I agree, and I understand the point. However, this won't help in *my* case. I cannot easily implement a category method for a class, since these objects don't know how to perform those actions required by the client. The kind of action performed depends on the "traits" (say, whether it is an associative container, an array of objects, a character representation, or a sequence of bytes, etc.) of the objects **and** the "context":
RXTraits* traits = [obj rx_traits]; // same as [[obj class] rx_traits];
if (traits.isAssociativeContainer) {
[obj enumerateKeysAndObjectsUsingBLock: /* do something depending on context */ ];
}
else if (traits.isOrderedSequence) {
[obj enumerateObjectsAtIndexesUsingBlock: /* do something depending on context */ ];
}
...
Passing the context through a category method would be possible, but this would result in many duplications of code - which is also a code smell ;)
Using the "traits" concept, isn't for free as well, though.
>
>> Asking for an object's class using isKindOfClass: is a definite code smell.
I wouldn't say that this is always the case. But most often I don't want to know the kind of class, but some more abstract "concept". So, asking the class is probably not what I want. Rather I want to know whether the object fulfills some promises or exhibits some behavior (the duck, you know). Then I agree, it is likely something that smells.
Andreas
_______________________________________________
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