Re: "context-aware" bindings
Re: "context-aware" bindings
- Subject: Re: "context-aware" bindings
- From: Charles Srstka <email@hidden>
- Date: Sun, 27 Feb 2011 19:42:51 -0600
On Feb 27, 2011, at 9:25 AM, Mikkel Eide Eriksen wrote:
>
> On 27/02/2011, at 11.39, Joanna Carter wrote:
>
>> Le 27 févr. 2011 à 10:07, Andy Lee a écrit :
>>
>>> On Feb 27, 2011, at 3:19 AM, Mikkel Eide Eriksen wrote:
>>>> I have a property on an object that would ideally return either its value or nil, depending on the context it's being called from.
>>>
>>> Can you tell us the name of the object and the property, and describe the different contexts? I'm having trouble imagining such a requirement.
>>>
>>>> I could do this with multiple selectors, but was wondering if there was a "cleaner" way of determining how it is being called.
>>>
>>> It seems to me a property that can return multiple values isn't really a property. It's either a method you pass a parameter to (to specify "context" -- which of course won't work for bindings), or it's multiple properties (i.e., multiple selectors -- what's not clean about that?).
>>
>> There is certainly a design problem here. Why would two different callers expect a different result from a property, when one of those results is going to be nil?
>>
>> If one of the callers is expecting nil returned, why bother calling the property?
>>
>> Some idea of the code would be useful.
>
> It would only return nil in some cases. I'm working on some Gedcom <-> Core Data code. All objects in Gedcom have a "tag" identifier. One such object is an "Event", with the generic tag EVEN. There are multiple subtypes of Event, such as BIRT (birth), DEAT (death), CONF (confirmation), etc.
>
> An Event can also have a "type", which in the case of generic EVENs is something for which no specific tag exists. So:
>
> Event with type "Birth" should become:
> 1 BIRT
> 2 DATE ...
> 2 PLAC ...
>
> generic Event with some type should become:
> 1 EVEN
> 2 TYPE Event Type
> 2 DATE ...
> 2 PLAC ...
>
> My current implementation of the type getter on the Event object checks to see if the type is one of the known tags (Birth, etc), and returns nil so as to avoid redundant data:
>
> 1 BIRT
> 2 TYPE Birth
> 2 DATE ...
> 2 PLAC ...
>
> I think I'll probably use a displayType property for bindings, and the internal type property for writing out to Gedcom. Another option would be to subclass Event into all the different types, but that seems overkill.
This sounds like a job for a NSValueTransformer subclass, really. I think that should be able to do exactly what you want.
Charles_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden