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.

Regards,
Mikkel



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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