[On Apr 2, 2009, at 15:24 , Michael Ash wrote:
yes/no/yes/no/yes/no...]
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.
This simply isn't true:
typedef const struct __CFArray * CFArrayRef;
struct __CFArray {
CFRuntimeBase _base;
CFIndex _count; /* number of objects */
CFIndex _mutations;
void *_store; /* can be NULL when MutableDeque */
};
That is a CFArray. Now you may *think* of a CFArray as all sorts of
things, but this is what a CFArray actually *is*.
It can be
distinguished from an array created using CFArrayCreate, just as it
can be distinguished from an array created using [NSArray array],
Glad that you agree that the test can be performed, which is different
from what you said before:
On Apr 1, 2009, at 21:44 , Michael Ash wrote:
The test cannot be performed, because the question does not make any
sense.
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)
C does not have the concept of an abstract class, as it does not have
the concept of class in the first place. A CFArray is a very concrete
C type. Again, you may *think* of it as being sort of like an
abstract class, but that is not what it is.
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.
NSArray does not have any sort of relationship with CFArray. I can
prove this on an Etch-a-Sketch.
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.
Actually, it is, but you don't seem to realize this.
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.
CFArray is not a class. In fact, CFArray doesn't even exist.
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.
Well, those things that you don't care about are the only things that
make your claim even remotely close to the truth.
The fact of the matter is
that these are just two names for the same type.
Let's ask the compiler:
-------- snip ----
NSArray *array=[NSArray array];
CFArrayRef cfarray;
id otherArray;
cfarray=array;
otherArray=cfarray;
--------- snip -----
cfarray.m:9: warning: assignment from incompatible pointer type
cfarray.m:10: warning: assignment from incompatible pointer type
So the compiler also disagrees with you that these are the same type.
You can *cast* them to be compatible, but they are not the same type.
There simply is no distinction between an NSArray and a CFArray at
runtime.
This is easily and provably false both at compile-time and runtime.
What is true is that frequently you can ignore those differences, and
that's a good thing.
Marcel
_______________________________________________
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
