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
