Re: A Challenge WAS Accessor method idioms...
Re: A Challenge WAS Accessor method idioms...
- Subject: Re: A Challenge WAS Accessor method idioms...
- From: Nicko van Someren <email@hidden>
- Date: Thu, 24 Mar 2005 20:56:51 +0000
On 24 Mar 2005, at 20:39, John Brownlow wrote:
On Mar 24, 2005, at 3:32 PM, Nicko van Someren wrote:
On 24 Mar 2005, at 19:11, John Brownlow wrote:
I'm a HUGE fan of Accessorizer but here is 50+ lines for a single
array. Let's say I have ten arrays, not at all unlikely... now it's
500 lines of mechanical code that I haven't ever read. Yuk. And I am
completely reliant on the genius of Accessorizer because believe me
I am NOT going to type those 500 lines myself and neither is anyone
else.
Perhaps the answer to this problem is to write the core, generic
functionality of Accessorizer as a category for NSObject and
implement methodForSelector: and respondsToSelector: with a
table-driven system that lets you specify the desired mode of access
settings for each instance variable. The generic accessor function
can tell which instance variable you care about by looking at the
selector passed in the hidden argument _cmd and the class
initialisation code could set up some simple hash tables on startup
to make sure that the lookup is fast.
an interesting idea... but don't you get the feeling that the cure is
worse than the disease?
In what way worse? The result will almost certainly be _more_
comprehensible; instead of having reams of accessor messages you just
have a static table at the top of the class definition describing each
of the instance variables to which you wish to offer access and how the
user gets to access them (e.g. by value, by copy, array manipulation
etc.) The performance will be impacted by the cost of a couple of
table lookups of more or less the same type as a cache hit in Objective
C's own selector mapping cache; a few dozen cycles at most. Of course
there would be nothing to stop you from writing traditional accessors
for variables which you expect to be accessed regularly if that cost is
too high. It seems to me to be the classic trade-off with regards to
there being a performance penalty on more generic (and thus more
maintainable) code.
Nicko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden