Re: Can a value transformer get its own registration name?
Re: Can a value transformer get its own registration name?
- Subject: Re: Can a value transformer get its own registration name?
- From: Mike Abdullah <email@hidden>
- Date: Thu, 12 Apr 2007 20:09:05 +0100
On 12 Apr 2007, at 19:33, Bill Cheeseman wrote:
on 2007-04-12 1:58 PM, Jim Correia at email@hidden wrote:
On Apr 12, 2007, at 1:33 PM, Bill Cheeseman wrote:
Of course I could do the same thing with multiple transformer
subclasses or,
as you pointed out, with a single subclass with a registered name
iVar to
use in the if-else chain. To my mind, the "generalized" subclass
approach
based on registered names and pointer comparisons is simpler to
implement,
both because I only need to write one subclass and I don't need to
mess with
iVars, -initWith... methods and all that. I just use the
registration naming
facility that NSValueTransformer already provides.
That's where we disagree. You only have to write one subclass. It it
just a matter of how you tell the instance how to do its work.
It is much easier, and straight forward, for an instance to have
those parameters directly available via iVars.
Trying to encode these in the registration name is not the way to go,
IMO. Especially given the considerations previously posted.
What I'm not getting is how you actually use a value transformer
instance in
your scenario, if you don't rely on the registration name to
distinguish
between instances having different behavior. The value transformer
field in
the view binding pane in the IB inspector requires a registration
name.
Or are you saying that you do rely on the registration name, but
only to get
the right instance -- and that the instance's behavior is then
determined by
the iVar you embedded in it when it was initialized?
This is correct
I concede that using an iVar in this way makes for more
understandable and
maintainable code, since a reader will see the importance and role
of the
ivar at first glance rather than having to find it isolated in the
-transformedValue: method. It's probably also easier to adjust as
you work
on an app-in-development.
--
Bill Cheeseman
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40mikeabdullah.net
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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