Leopard Properties and 'non-nil' declaration

[André Pang]

On 06/01/2008, at 2:43 PM, Bill Bumgarner wrote:

> Seriously, though, there are cases where mutablecopy makes a lot of  
> sense.  Specifically, if your object model is such that your object  
> wants to take ownership of the contents of the array and changes  
> therein.

Right, agreed.  I did think of that case, but thought that it was a  
little unusual in that you would have to access the ivar directly  
inside your class's code to update its contents, rather than using the  
property syntax (otherwise you'd be making a mutable copy of the  
object on every update).  So mutable-copy properties requires some  
care in usage, but I suppose it's no more care needed than with retain  
semantics.

While we're on the subject of properties, I wonder if I can subvert  
the topic a bit...

I was pondering submitting an enhancement request to have a "non-nil"  
property declaration, e.g.

  @property (retain, nonnil) id foo;

That declaration would only apply to Objective-C objects[1], and hint  
to the user that setting the property to a nil object is illegal.   
@synthesize would be expected to check if the object being passed in  
is nil; if it is, it can throw an exception or something else sensible.

I think non-nil setters are a common-enough scenario that it'd justify  
being an additional property declaration.  Right now I'm resorting to  
writing my own setters for properties that I want to be non-nil, which  
is OK, but hey, the less work I have to do, the better :).

I'm happy to submit a formal radar request for this, but I thought I'd  
check with others first whether I'm on crack.

1. I realise that being only applicable to Objective-C objects  
restricts the generality of the property declaration, but hey, assign/ 
retain/copy(/mutablecopy) are all object-specific already anyway :).


-- 
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>