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:37:42 -0800
Done right, I'm afraid the example is not trivially typed into an email message. ;-) This would be a significant mechanism, although one that could be shared by any classes that wished to make use of it.
Mike Ferris
Begin forwarded message:
From: John Brownlow <email@hidden>
Date: March 24, 2005 1:02:23 PM PST
To: Cocoa List Mailing <email@hidden>
Subject: Re: A Challenge WAS Accessor method idioms...
so how would the code look? example?
On Mar 24, 2005, at 3:56 PM, Nicko van Someren wrote:
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.
--
John Brownlow
Deep Fried Films, Inc
http://www.johnbrownlow.com
http://www.pinkheadedbug.com
_______________________________________________
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