Re: Interpretation of static types in Cocoa [Was: Immutable discomfort]
Re: Interpretation of static types in Cocoa [Was: Immutable discomfort]
- Subject: Re: Interpretation of static types in Cocoa [Was: Immutable discomfort]
- From: Glenn Andreas <email@hidden>
- Date: Fri, 19 Dec 2003 11:16:26 -0600
>> If you define your API to accept an immutable object (aka NSArray)
then folks should either give you an immutable object or mutable
one but abstain from changing anything in it.
Actually, doesn't taking an NSArray as an argument imply that the
the method won't change it (not that the caller isn't free to
pass in an NSMutableArray?)
Well, I've seen some people using or advocating such conventions,
including some skilled Cocoa engineers at Apple.
For instance, I've seen it expressed, quite clearly, like that:
----- quote ----
"In Cocoa, the types declared for arguments and return values in the
API are more about what the caller can do with the return value or
what the method will do with the argument rather than what the
return value really will be or what the argument must be."
------------------
However, in the spirit of good technical debate, I'd like to state
it that, IMHO, these conventions are bad and should not be used.
They leads to numerous problems, including the fact that, AFAIK,
they go against decades of research and refinement in the definition
and interpretation of type systems by the whole object-oriented
programming community.
[snip]
I'd like to strongly advise anyone using Cocoa to stick to the well
established approach described here when designing Objective-C
classes. An approach that we find pervasively documented and used in
other object-oriented languages and frameworks throughout the
industry. Using conventions incompatible with it equals to giving up
any hope in a reasonably sound, general and intuitive interpretation
of our type system. This leads to unintuitive idioms, complexity,
unintended limitations, inconsistent interpretation of the type
system, and brittle code (and, if this is not enough, this might
also make your car consume more oil ;-)
While I agree with you in principle, and in practice for languages
like C++, these rules don't quite scale well to the dynamic nature of
Objective-C (and especially when viewed that the object model of
Obj-C is based on Smalltalk, and not Simula).
For example, if you are using distributed objects, you will get back
an instance of an NSProxy. That proxy, of course, stands in place
for something on the other end of the wire, which you interact with
locally as if it were really that other object. So if you got back a
proxy to an NSArray, you could do something to it that will still
return an NSProxy - and not an NSArray. So even though the method
says "NSArray *", you may be getting an NSProxy (which doesn't even
have the same root class) - yet you should treat it as if it were an
NSArray, performing those methods that are appropriate for an NSArray.
I've seen this philosophy labelled as "duck typing" (if it looks like
a duck, and quacks like a duck, it is a duck, as well as a pun on
"duct taping" since you can then tape together objects that weren't
originally designed to work together, but since they understand how
to quack, that's all they need).
Perhaps a better solution is to use protocols all over the place (or
treat static typing info as if it were a protocol rather than typing
info), but declarling evering as a protocol and then a class that
implements that protocol may result in an unecessarly layer of
obfuscation. Still, if you view "(NSArray *)" in a method
declaration as the moral equivalent of "(id <NSArray>)", that seems
to encapsulate the intent rather well - it promises that the object
will quack like an NSArray, not that it is an NSArray (or even a
subclass of an NSArray).
--
Glenn Andreas email@hidden
Theldrow, Blobbo, Cythera, oh my!
Be good, and you will be lonesome
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.