Leopard Properties and 'non-nil' declaration

FROM : André Pang
DATE : Sun Jan 06 05:07:15 2008

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/>