On Thu, Apr 2, 2009 at 6:11 PM, Marcel Weiher <marcel.wei...@gmail.com> wrote: > > On Apr 2, 2009, at 13:54 , Michael Ash wrote: > >> On Thu, Apr 2, 2009 at 3:20 PM, Marcel Weiher <marcel.wei...@gmail.com> >> 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.
No, it is correct in all cases. The question is not valid and does not make sense. The custom NSArray subclass is still a CFArray. It can be distinguished from an array created using CFArrayCreate, just as it can be distinguished from an array created using [NSArray array], but that's an entirely different question. >> 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. I don't really care about these implementation details. From the point of view of the API contract, CFArray is an abstract class (yes, implemented in C) with many potential implementations under the hood. It makes no difference that some of these have special cases which are handled here, and some have special cases which are handled over there. > 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 Of course it doesn't have any relationship with NSCFArray. I never said it did. I said that it has a relationship with *NSArray*, and thus CFArray. There is a difference between those two, no matter how much you say there is not. > Allowing your logic, just about any two classes would actually be > equivalent, because virtually all of them have NSObject as a common > ancestor. Come on, this is not even remotely what I said. Nowhere did I say that two different classes are equivalent. What I did say was that two different classes which both inherit from a common superclass are both instances of that superclass. That, I'm sure, you will agree with. >> 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. I don't really care what makes it happen. The fact of the matter is that these are just two names for the same type. That there is a One True Implementation provided by the system, and an allowance for custom implementations elsewhere, does not change that fact one whit. There simply is no distinction between an NSArray and a CFArray at runtime. There is a distinction between an *NSCFArray* and other NSArray subclasses, but that's not even *remotely* close to being the same question. Mike _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
