Others have addressed your concern about automated generation of
accessors to relieve the programmer of that drudgery. I'd like to
address something else...
On Jun 2, 2008, at 4:30 PM, john darnell wrote:
To refresh everyone's memory, key-value coding is the convention
that says
for every object the programmer defines, setting up a setter function
and a getter function as so:
That's not really what key-value coding is about. Quoting from
Apple's Key-Value Coding Programming Guide <http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Overview.html
>, under the heading "What is Key-Value Coding?":
Key-value coding is a mechanism for accessing an object’s
properties indirectly, using strings to identify properties, rather
than through invocation of an accessor method or accessing them
directly through instance variables.
Notice that both accessors and direct access to ivars are on the right-
hand side of "rather than". So, key-value coding is not the
convention about writing accessors. It's a mechanism, which
incidentally may exploit methods named according to convention, for
accessing an object's properties.
The important thing to think about is "properties" and what they are.
Properties are _not_ the ivars. It is entirely possible, and not even
all that rare, for a class to have a property for which there is no
corresponding ivar. A property is part of the public class
interface. It's part of the _concept_ of the class. It's a named
attribute or relationship of the objects being described by the
class. (Objective-C 2.0 adds support for explicitly declaring
properties with @property, but the concept is more general than that.)
A key is the name of a property.
An instance variable should be thought of as an implementation detail
-- it's one possible way to implement a property of a class. While
key-value coding will access instance variables directly if necessary,
one should put properties where they belong: in the interface, as
methods conforming to certain naming conventions. (Even methods which
don't conform to the KVC naming conventions can constitute the
declaration of a property in the most general sense, but they'll be
less useful and will confuse others who read your code.)
I recommend reviewing the Object Modeling section of the Cocoa
Fundamentals Guide: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_5.html
So, getting back to your original concern about the tedious task of
writing repetitive accessors for your instance variables... It seems
to me that such a concern is a sign of getting things backward.
You're starting your thinking with the instance variables and then
being annoyed at having to write what seems like superfluous code --
the accessors -- by rote. Try thinking about things in this order,
instead: think of the design of your class, identify the properties
that the class should have, declare them in the class's interface as
(KVC-conforming) accessors, and then set about implementing the
property by writing the implementation of those accessors.
Ultimately, you may decide to add an instance variable to the class as
part of the implementation of the property, or you may not. In any
case, thinking about properties in this manner assigns the appropriate
relative importance to instance variables and accessors and may
clarify why the latter are not "generated from" the former.
Cheers,
Ken_______________________________________________
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 [EMAIL PROTECTED]
