Re: blocks and id
On 15.12.2012, at 01:44, Uli Kusterer wrote:
>
> On 15.12.2012, at 01:38, Uli Kusterer wrote:
>
>> On 12.12.2012, at 10:03, Andreas Grosam 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: blocks and id
On 15.12.2012, at 01:38, Uli Kusterer wrote: > On 12.12.2012, at 10:03, Andreas Grosam 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? 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: Drat, accidentally hit 'send'. That should be 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. > Asking for an object's class using isKindOfClass: is a definite code smell. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On 12.12.2012, at 10:03, Andreas Grosam 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? 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: 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. Asking for an object's class using isKindOfClass: is a definite code smell. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.masters-of-the-void.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On Dec 12, 2012, at 5:24 AM, Andreas Grosam wrote: > And, it can be a block as well, where the block is responsible to feed the > consumer (the id) with data when it has bytes > available when the request is active. > You can do this with the same method, same API. Well, it MUST, otherwise the > number of combinations of the various types yielding different methods, would > explode. You don’t have to do it that way. An alternative is to make a class that can wrap any of those objects and remembers which one it is; then you can call [Parameter parameterWithString:] or +parameterWithNumber: or +parameterWithBlock: or whatever, and have methods on Parameter that can tell you what sort of object it was created with. (NSValue has a very similar design — note that it can store a large number of different types without having to use a separate class for each one, or requiring the caller to use -isKindOfClass: to find out if a value is a point or a rect or a double.) If you don’t want to do that, you should at least make a wrapper class around a block, like RXBlock. Basically just a simple class whose instances hold onto a block pointer. Then you can check whether a parameter is an instance of RXBlock, and if it is, get the block value from it. It’s only a bit more work for the client who has to call an RXBlock factory method instead of just passing in a block literal directly. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On 12 Dec 2012, at 14:14, Jean Suisse wrote: > On 12 déc. 2012, at 13:02, Mike Abdullah wrote: > >> Why does your code care if some unknown object is a block? This is a strong >> sign of a bad design. > > > As far as I am concerned, I can think of at least two or three legitimate > reasons to care wether an unidentified object is a block or not. > But you seem pretty certain. So you must have had more informations than the > rest of us > – sorry, just thinking out loud. No extra information; just experience and a knowledge of the Cocoa APIs. > > To actually answer the question, I fear that not much can be done. > Personally, I would go for Andreas' current solution and if the app is > commercial, I would make sure to test & fix it before each public MAC OS > release, so that users can upgrade the app before upgrading the system (and > also check the OS version at each launch to detect if they didn't upgrade). Seriously, you'd recommend a fragile solution that relies on private API and needs regular testing, over simply having two or more methods? > > Otherwise, maybe this could work depending on the situation: > -(whatever)processSomething:(id)something > andKeepInMindThatsABlock:(BOOL)isBlock; Well once you've done that, surely you might as well just have two separate methods?! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On 12 déc. 2012, at 13:02, Mike Abdullah wrote: > Why does your code care if some unknown object is a block? This is a strong > sign of a bad design. As far as I am concerned, I can think of at least two or three legitimate reasons to care wether an unidentified object is a block or not. But you seem pretty certain. So you must have had more informations than the rest of us – sorry, just thinking out loud. To actually answer the question, I fear that not much can be done. Personally, I would go for Andreas' current solution and if the app is commercial, I would make sure to test & fix it before each public MAC OS release, so that users can upgrade the app before upgrading the system (and also check the OS version at each launch to detect if they didn't upgrade). Otherwise, maybe this could work depending on the situation: -(whatever)processSomething:(id)something andKeepInMindThatsABlock:(BOOL)isBlock; Jean ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On 12 Dec 2012, at 13:24, Andreas Grosam wrote:
>
> On 12.12.2012, at 13:02, Mike Abdullah wrote:
>
>>
>> On 12 Dec 2012, at 09:57, Andreas Grosam wrote:
>>
>> Why does your code care if some unknown object is a block? This is a strong
>> sign of a bad design.
>
> Oh, then a lot of common Cocoa patters like dug typing
I presume you mean "duck typing"? Duck typing is pretty much the opposite of
what you're trying to do. Duck typing is being handed an object and told it
meets a certain requirement. Rather than trying to test if it really is of the
expected *class*, you message it anyway on the understanding that it will
behave as you expect.
The point is that you care whether the object *behaves like* a duck; not
whether it actually is a duck.
> and the usage -respondsToSelector:, -conformsToProtocol:, or any other
> introspection are a bad design, too. ;)
These methods contribute to duck typing sort of behaviour in Cocoa, not the
approach you describe below. It's worth noting that Cocoa actually uses these
methods pretty sparingly in practice.
>
>
> I don't like it either, but the alternative would be a quite elaborate
> approach and would require to define categories for every class that is
> possibly involved in this particular case.
Writing category methods seems no more elaborate than writing a big series of
if statements checking the class of an object.
> AND it would requite a respondsToSelector anyway,
Not true; if the object doesn't implement the selector, you can consider that
to be a programmer error and throw an exception.
> AND would require some mechanism that "processes" a block and the other
> objects through sending the object a common single message.
>
>
> The reason why I would like to have this is a rather generic interface which
> shall be as flexible and as convenient as possible. It is used for a network
> library when generating HTTP messages. For example, the following snippet
> creates a Foundation representation of a multipart/form-data part suitable to
> upload a file to a server:
>
> id part6 =
> [RXMultipartFormdataSource makeFilePartWithName:@"submit"
> fileName:@"data2.txt"
>
> headers:@{@"content-type":@"text/plain"}
> value:[NSData
> dataWithBytes:"0123456789" length:10]];
>
>
>
>
> The construction of a valid sequence of bytes constituting various HTTP
> headers is more than cumbersome.
>
> In this snipped, the parameter `headers` are defined as a NSDictionary.
> However, it could also be a NSData containing a valid sequence of bytes
> constituting *one* header, or *many* headers, or an NSArray of NSDatas
> constituting a number of headers. And since a header may have a set of
> parameters, a header entry in the dictionary may have a params dictionary as
> well, and so force. The parameter `headers` (and the others, too) will simply
> pass a serialization process, which eventually generates a NSData object -
> constituting one or more HTTP message headers.
>
> Likewise, parameter `value` constituting the body part can be anything that
> can be eventually converted to something that is a valid byte sequence for
> the body data of a multi part, conforming to the context defined through the
> headers already set. If the header would be empty, and value would have been
> a NSString, the string would be encoded properly with a default encoding
> (UTF-8), and the headers would be set accordingly (-> "Content-Type:
> text/plain; charset=utf8").
>
> If the parameter `value` would be NSNumber for instance, the NSNumber would
> be first converted to a NSString, and then encoded as mentioned above.
> If a Content-Type header with a charset definition has been defined already
> and the value is a NSString, the string will be encoded as stated in the
> charset parameter value (e.g. charset=utf8).
>
> The parameter value can be a file URL, too -- in which case a more elaborated
> mechanism is used to construct the body of the whole message during the
> request is active.
>
> And, it can be a block as well, where the block is responsible to feed the
> consumer (the id) with data when it has bytes
> available when the request is active.
>
>
> You can do this with the same method, same API. Well, it MUST, otherwise the
> number of combinations of the various types yielding different methods, would
> explode.
This is going to end badly, believe me. Look around Cocoa, you will find very,
very few APIs, if any, that behave the way you want this one to. You want
separate methods for the different types of input to handle. If you accomplish
this by defining a protocol that a variety of objects conform to, that's fine;
then you only need to publish two methods — one for blocks, and one for other
object types.
___
Cocoa-dev
Re: blocks and id
On 12.12.2012, at 13:02, Mike Abdullah wrote:
>
> On 12 Dec 2012, at 09:57, Andreas Grosam wrote:
>
> Why does your code care if some unknown object is a block? This is a strong
> sign of a bad design.
Oh, then a lot of common Cocoa patters like dug typing and the usage
-respondsToSelector:, -conformsToProtocol:, or any other introspection are a
bad design, too. ;)
I don't like it either, but the alternative would be a quite elaborate approach
and would require to define categories for every class that is possibly
involved in this particular case. AND it would requite a respondsToSelector
anyway, AND would require some mechanism that "processes" a block and the other
objects through sending the object a common single message.
The reason why I would like to have this is a rather generic interface which
shall be as flexible and as convenient as possible. It is used for a network
library when generating HTTP messages. For example, the following snippet
creates a Foundation representation of a multipart/form-data part suitable to
upload a file to a server:
id part6 =
[RXMultipartFormdataSource makeFilePartWithName:@"submit"
fileName:@"data2.txt"
headers:@{@"content-type":@"text/plain"}
value:[NSData
dataWithBytes:"0123456789" length:10]];
The construction of a valid sequence of bytes constituting various HTTP headers
is more than cumbersome.
In this snipped, the parameter `headers` are defined as a NSDictionary.
However, it could also be a NSData containing a valid sequence of bytes
constituting *one* header, or *many* headers, or an NSArray of NSDatas
constituting a number of headers. And since a header may have a set of
parameters, a header entry in the dictionary may have a params dictionary as
well, and so force. The parameter `headers` (and the others, too) will simply
pass a serialization process, which eventually generates a NSData object -
constituting one or more HTTP message headers.
Likewise, parameter `value` constituting the body part can be anything that can
be eventually converted to something that is a valid byte sequence for the body
data of a multi part, conforming to the context defined through the headers
already set. If the header would be empty, and value would have been a
NSString, the string would be encoded properly with a default encoding (UTF-8),
and the headers would be set accordingly (-> "Content-Type: text/plain;
charset=utf8").
If the parameter `value` would be NSNumber for instance, the NSNumber would be
first converted to a NSString, and then encoded as mentioned above.
If a Content-Type header with a charset definition has been defined already and
the value is a NSString, the string will be encoded as stated in the charset
parameter value (e.g. charset=utf8).
The parameter value can be a file URL, too -- in which case a more elaborated
mechanism is used to construct the body of the whole message during the request
is active.
And, it can be a block as well, where the block is responsible to feed the
consumer (the id) with data when it has bytes
available when the request is active.
You can do this with the same method, same API. Well, it MUST, otherwise the
number of combinations of the various types yielding different methods, would
explode.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: blocks and id
On 12 Dec 2012, at 09:57, Andreas Grosam wrote: > > On 12.12.2012, at 10:19, Charles Srstka wrote: > >> On Dec 12, 2012, at 3:03 AM, Andreas Grosam wrote: >> >>> How can I check at runtime whether an object (id) is actually a block, and >>> not another kind of object? >> >> I don't think there's any good way of doing that right now. You could check >> the class of the block, but since the block classes are completely >> undocumented AFAIK, there's no guarantee that the class names won't change >> in some future release of OS X and break your code. >> >> Charles >> > > Thanks for the reply. I feared that. > > Currently, I resort to > > > if ([obj isKindOfClass: NSClassFromString(@"NSBlock")]) > … > > which evaluates to YES if `obj` is a block. However, NSBlock is not a public > class, thus: NSClassFromString(@"NSBlock") which "works" as the time of > writing in Mac OS, and returns a class whose name is "NSBlock" (the real > block classes are named differently). Why does your code care if some unknown object is a block? This is a strong sign of a bad design. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On Dec 12, 2012, at 6:36 AM, jonat...@mugginsoft.com wrote:
> On 12 Dec 2012, at 09:57, Andreas Grosam wrote:
>> On 12.12.2012, at 10:19, Charles Srstka wrote:
>>> On Dec 12, 2012, at 3:03 AM, Andreas Grosam wrote:
>>>
How can I check at runtime whether an object (id) is actually a block, and
not another kind of object?
>>>
>>> I don't think there's any good way of doing that right now. You could check
>>> the class of the block, but since the block classes are completely
>>> undocumented AFAIK, there's no guarantee that the class names won't change
>>> in some future release of OS X and break your code.
>> Thanks for the reply. I feared that.
>>
>> Currently, I resort to
>>
>>
>> if ([obj isKindOfClass: NSClassFromString(@"NSBlock")])
>> …
>>
>> which evaluates to YES if `obj` is a block. However, NSBlock is not a public
>> class, thus: NSClassFromString(@"NSBlock") which "works" as the time of
>> writing in Mac OS, and returns a class whose name is "NSBlock" (the real
>> block classes are named differently).
>>
>> I wish there was something official.
> You could perhaps make this a little less fragile.
>
>typedef void (^MyBlockType)(void);
>
>// we know this is a block
>void (^isaBlock)(void) = ^(void) {};
>
>MyBlockType aBlock = ^(void) {NSLog(@"I am a block");};
>
>id qua = aBlock;
>
>if ([qua isKindOfClass:[isaBlock class]]) {
> ((MyBlockType)qua)();
>}
This will not work for all cases. For example, a stack-based block versus one
that's been copied to the heap will have different classes, which are probably
siblings (i.e. [[_NSConcreteStackBlock class] isKindOfClass:[_NSMallocBlock
class]] == NO).
My solution to this issue has been the "exclusion" case, i.e. if (![obj
isKindOfClass:[anything my API contract says I can receive that isn't a
block]]) { /* it's a block by process of elimination */ }. Obviously this won't
work if your API contract says you can receive arbitrary objects.
-- Gwynne Raskind
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: blocks and id
On 12.12.2012, at 12:36, jonat...@mugginsoft.com wrote:
> You could perhaps make this a little less fragile.
>
>typedef void (^MyBlockType)(void);
>
>// we know this is a block
>void (^isaBlock)(void) = ^(void) {};
>
>MyBlockType aBlock = ^(void) {NSLog(@"I am a block");};
>
>id qua = aBlock;
>
>if ([qua isKindOfClass:[isaBlock class]]) {
> ((MyBlockType)qua)();
>}
>
> Jonathan
Unfortunately, this doesn't work if the block `aBlock` has a closure, and
because of this becomes a different class, so that ([qua
isKindOfClass:[isaBlock class]]) evaluates to `No`.
The easiest way would certainly be a reliable statement that the common base
class for all blocks would be `NSBlock` (or something else).
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: blocks and id
On 12 Dec 2012, at 09:57, Andreas Grosam wrote:
>
> On 12.12.2012, at 10:19, Charles Srstka wrote:
>
>> On Dec 12, 2012, at 3:03 AM, Andreas Grosam wrote:
>>
>>> How can I check at runtime whether an object (id) is actually a block, and
>>> not another kind of object?
>>
>> I don't think there's any good way of doing that right now. You could check
>> the class of the block, but since the block classes are completely
>> undocumented AFAIK, there's no guarantee that the class names won't change
>> in some future release of OS X and break your code.
>>
>> Charles
>>
>
> Thanks for the reply. I feared that.
>
> Currently, I resort to
>
>
> if ([obj isKindOfClass: NSClassFromString(@"NSBlock")])
> …
>
> which evaluates to YES if `obj` is a block. However, NSBlock is not a public
> class, thus: NSClassFromString(@"NSBlock") which "works" as the time of
> writing in Mac OS, and returns a class whose name is "NSBlock" (the real
> block classes are named differently).
>
> I wish there was something official.
>
You could perhaps make this a little less fragile.
typedef void (^MyBlockType)(void);
// we know this is a block
void (^isaBlock)(void) = ^(void) {};
MyBlockType aBlock = ^(void) {NSLog(@"I am a block");};
id qua = aBlock;
if ([qua isKindOfClass:[isaBlock class]]) {
((MyBlockType)qua)();
}
Jonathan
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: blocks and id
On 12.12.2012, at 10:19, Charles Srstka wrote: > On Dec 12, 2012, at 3:03 AM, Andreas Grosam wrote: > >> How can I check at runtime whether an object (id) is actually a block, and >> not another kind of object? > > I don't think there's any good way of doing that right now. You could check > the class of the block, but since the block classes are completely > undocumented AFAIK, there's no guarantee that the class names won't change in > some future release of OS X and break your code. > > Charles > Thanks for the reply. I feared that. Currently, I resort to if ([obj isKindOfClass: NSClassFromString(@"NSBlock")]) … which evaluates to YES if `obj` is a block. However, NSBlock is not a public class, thus: NSClassFromString(@"NSBlock") which "works" as the time of writing in Mac OS, and returns a class whose name is "NSBlock" (the real block classes are named differently). I wish there was something official. Andreas ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: blocks and id
On Dec 12, 2012, at 3:03 AM, Andreas Grosam wrote: > How can I check at runtime whether an object (id) is actually a block, and > not another kind of object? I don't think there's any good way of doing that right now. You could check the class of the block, but since the block classes are completely undocumented AFAIK, there's no guarantee that the class names won't change in some future release of OS X and break your code. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
blocks and id
How can I check at runtime whether an object (id) is actually a block, and not another kind of object? Andreas ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
