Re: A Challenge WAS Accessor method idioms...
Re: A Challenge WAS Accessor method idioms...
- Subject: Re: A Challenge WAS Accessor method idioms...
- From: Mike Ferris <email@hidden>
- Date: Fri, 25 Mar 2005 07:35:09 -0800
While auto-accessors is a neat idea, and one that I have thought about a bit, it would have to be done in a way that does not involve forwarding (at least after the first use).
There are ways to accomplish this, perhaps along the lines of how auto-KVO is implemented. In this case it might even be doable without dynamic subclassing. I may look into this eventually.
Of curse, I still want the accessors declared in my header and documented. And, of course, then the compiler's gonna whine about my "incomplete" class...
Mike Ferris
Begin forwarded message:
From: Nicko van Someren <email@hidden>
Date: March 24, 2005 12:32:45 PM PST
To: John Brownlow <email@hidden>
Cc: Cocoa List Mailing <email@hidden>
Subject: Re: A Challenge WAS Accessor method idioms...
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.
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
_______________________________________________
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