Re: Toll-free bridge type at runtime
Re: Toll-free bridge type at runtime
- Subject: Re: Toll-free bridge type at runtime
- From: Clark Cox <email@hidden>
- Date: Thu, 2 Apr 2009 16:12:32 -0700
On Thu, Apr 2, 2009 at 3:11 PM, Marcel Weiher <email@hidden> wrote:
>
> On Apr 2, 2009, at 13:54 , Michael Ash wrote:
>
>> On Thu, Apr 2, 2009 at 3:20 PM, Marcel Weiher <email@hidden>
>> wrote:
>>>
>>> On Apr 1, 2009, at 21:44 , Michael Ash wrote:
>>>
>>>> On Thu, Apr 2, 2009 at 12:33 AM, Ryan Joseph
>>>> [distinguishing between NSArray and CFArray]
>>>> The test cannot be performed, because the question does not make any
>>>> sense.
>>>
>>> While this answer is mostly true for what the original poster is trying
>>> to
>>> accomplish (as far as I can tell), it is actually not true.
>>>
>>> An NSCFArray and a CFArray are indistinguishable as described, and if you
>>> as
>>> for an NSArray, you will typically get an NSCFArray.
>>>
>>> However, an actual NSArray that is not an NSCFArray will be different and
>>> distinguishable. This distinction is also not just academic, but quite
>>> important because it is used by CoreFoundation to know wether to call its
>>> own functions or send a message to the object in question, allowing
>>> custom
>>> NSArray subclasses to be used in CFArray calls.
>>
>> No, you're examining an entirely different question, which is whether
>> a particular object is the built-in provided NSArray subclass or a
>> custom subclass.
>
> No. I am examining the question wether a CFArray can be distinguished from
> an NSArray:
>
> On Apr 1, 2009, at 21:44 , Michael Ash wrote:
>
>>> I'm trying to determine at runtime if a type is CoreFoundation or Cocoa,
>>> for
>>> example NSArray/CFArray. [...]
>>
>> The test cannot be performed, because the question does not make any
>> sense.
>
> Your answer is correct if and only if the NSArray in question is a
> NSCFArray. If the NSArray in question is not a NSCFArray, the question is
> valid (thought possibly not what the original author intended) and the test
> can be easily performed.
>
>> Of course you can tell those apart, just like you can
>> distinguish between an NSTextField and an NSButton. But they're *both*
>> NSViews, and any NSArray subclass is still an NSArray. And any NSArray
>> is also a CFArray.
>
> This turns out not to be the case.
>
> 1. C
>
> If you look at it from the C perspective, a CFArray is a very specific
> structure that has no relationship to your NSArray subclass. So in CF, the
> statement is clearly false. However, the CFArray functions have
> special-case code to handle different types of objects transparently.
> However, for me that "if" statement clearly shows that they are *different*
> rather than the same, otherwise you wouldn't need the if statement.
No, from the C perspective, a CFArrayRef is an opaque pointer that can
be passed to the functions that make up the CFArray API. Anything that
can be passed to those functions is, from the perspective of a C
programmer, a CFArray. This includes NSArray and any of its
subclasses.
To a C programmer working at the CF level, a CFArray *is a* NSArray.
(Implementing CFArray is another story, but that is a detail hidden by
the API)
> 2. Objective-C
>
> From the Objective-C perspective, the equivalence is NSCFArray = CFArray.
> However, my custom NSArray subclass inherits from NSArray, not NSCFArray.
> It does not have any relationship with NSCFArray except a common ancestor:
>
> NSArray
> / \
> NSCFArray MYNSArray
>From the Objective-C perspective, there is no such thing as NSArray;
it is a class cluster, and any object that implements the required
methods can be treated as an NSArray; NSCFArray meets that criteria,
as does a custom subclass of NSArray; they are all NSArrays.
> Allowing your logic, just about any two classes would actually be
> equivalent, because virtually all of them have NSObject as a common
> ancestor.
If they implement the same methods and provide the same functionality,
then they *are* equivalent. If it walks like an NSArray and quacks
like an NSArray it *is* an NSArray.
>> It may have a different implementation from the
>> normal CFArray, but there's nothing weird about that: welcome to
>> object oriented programming.
>
> The compatibility that you see and that is confusing you is not due to the
> fact that there is an isa relationship, but due to non-isa compatibility and
> lots of hard-coded work.
Yes, but that hard-coded work is an implementation detail to *provide*
the isa compatibility.
--
Clark S. Cox III
email@hidden
_______________________________________________
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