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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to