Re: KVC and KVO for arrays
Re: KVC and KVO for arrays
- Subject: Re: KVC and KVO for arrays
- From: Adam P Jenkins <email@hidden>
- Date: Thu, 14 Feb 2008 01:47:34 -0500
I agree with everything you said below regarding static type checking,
and the advantages of getting the compiler to do as much checking as
possible for you. For work I do a lot of Java, C++, and Python
programming, so I do have some other languages to compare ObjC to.
I've just come to accept that when using ObjC and Cocoa especially,
there are a lot of potential errors that don't get caught until
runtime even if I do try to use accessor methods and static types as
much as possible. For instance there are no templates or generics in
ObjC so container classes like arrays and sets can contain different
types of objects than you expect. There are many methods throughout
the Cocoa APIs which just return id. When using bindings, or
creating GUIs with Interface Builder you're forced to use strings to
refer to properties all the time whether or not you've defined
accessors. It's very easy to end up with incorrect names in a binding
or connection, and the error messages you get are no more informative
if you've defined an accessor method than if you haven't. And unlike
Python or Java, the ObjC runtime doesn't give me any nice stack trace
showing me where the problem occurred; I just get a message in the
console.log or system.log saying that an attempt was made to access a
non-existent property. If you've ever spent an hour poring over all
the bindings and connections in Interface Builder trying to spot the
misspelling that's causing a problem, you'll know what I mean.
So the upshot of my little rant is that it doesn't always seem that
useful to me to create accessor methods in ObjC if I don't have to,
like it would be in Java or C++. It really depends on how the class
will be used. If I'm going to be writing a lot of code by hand which
uses the class then it's certainly worth adding accessors. If I'm
mainly going to be using the class with controllers and bindings, then
it doesn't seem to buy me much to add accessors if the default KVC
methods do what I want, since the way bindings work in Cocoa doesn't
take any advantage of static type checking.
To use my Party class as an example, if I was going to be writing a
lot of code which used the Party class, then I'd certainly rather not
have to write [party mutableArrayValueForKey:@"attendees"] too many
times. On the other hand, if the Party class was mainly going to be
used just as the model behind a GUI which let you edit the object, and
I just needed to bind the attendees property to an array controller,
then there wouldn't be much advantage to me writing my own accessor
methods compared to just using the functionality provided by
mutableArrayValueForKey:. Either way I have to specify the binding to
the attendees property as a string, and if I spell it wrong I won't
get notified until runtime.
Adam
On Feb 13, 2008, at 6:33 PM, Jens Alfke wrote:
On 13 Feb '08, at 11:24 AM, Adam P Jenkins wrote:
The kvoColors method is not necessary, and you can leave it out if
you think it confuses things.
Yeah, but then clients of your class have to access your property
with really ugly calls like
NSMutableArray *attendees = [party
mutableArrayValueForKey:@"attendees"];
This is really bad form, IMHO, because it breaks both object
encapsulation and compile-time method checking:
(1) There's nothing in the Party class that indicates "attendees" is
public. I could use the same technique to access any private
instance variable of a class, with neither compiler nor runtime
warnings. The "valueForKey" family of messages remind me of the old
PEEK and POKE in BASIC.
(2) If I misspell the key as "atendees", I won't get any compile-
time warning, just an exception at runtime.
(3) If the instance variable 'party' is by mistake typed as, say
Person* instead of Party*, I won't get a compile-time warning about
Person not having an "attendees" property.
(4) This is also 26 more characters to type, and much harder to
read, than "[party attendees]".
To some degree this is a matter of taste, but if I didn't care about
type-checking or data encapsulation, I'd be coding in Python
instead :) (and save a lot more than 26 characters; Python is hella
compact compared to Obj-C.)
—Jens
_______________________________________________
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