Re: NSKeyValueBindingCreation Leak
Re: NSKeyValueBindingCreation Leak
- Subject: Re: NSKeyValueBindingCreation Leak
- From: Quincey Morris <email@hidden>
- Date: Fri, 29 Jan 2010 03:42:50 -0800
On Jan 28, 2010, at 21:15, Richard Somers wrote:
> As I understand it, exposing the binding relates to exposing the binding to Interface Builder. Since I am not using Interface Builder exposing the binding is a non-issue.
It's not entirely clear. The NSKeyValueBindingCreation informal protocol lists a number of methods, but does not specify which are required for conformity. The question of whether an implementation conforms may or may not be significant to the binding mechanism, even without IB involvement. My point here and in a number of other places is that you're assuming that undocumented but observed implementation behavior is safe. Maybe the documentation is incomplete, or maybe the implementation may change. In the absence of further information, you're rolling dice.
> Regarding the "true binding name" that is something that has been confusing. At first I thought there was something magic in the "binding name". The documentation states that the first parameter for -bind:toObject:withKeyPath:options: is "The key path for a property of the receiver previously exposed using the exposeBinding: method." If we are not using Interface Builder then it simply becomes "The key path for a property of the receiver". My instance variable "array" is a property of "CustomObject" and so I think this is why this works as advertised.
The documentation is wrong, perhaps trivially or perhaps significantly. The currently observed behavior is that the first parameter can be *either* a property name *or* a binding name. (The "value" binding, present in many interface objects, is an example of a binding name that doesn't match any property name.) It's an unsettled question what the parameter is supposed to be, in terms of the API contract. (No one has chimed in to any discussion in the past 2 years with an official opinion. Note that IB doesn't provide any mechanism to bind *from* an arbitrary property, only a named binding, FWIW.) It's also an unsettled question whether specifying a property name as the first parameter even behaves correctly under all circumstances. In particular, I don't know that anyone has ever reported the result of passing an actual key path (xxx.yyy). That may or may not work, and may or may not be intended to work. So see above under rolling the dice.
> You do have a point here. Apples documentation is really geared towards a "binding" being what you see in Interface Builder which behind the scenes appears to be a multitude of moving pieces and parts. Programmatic bindings on the other hand are somewhat of a black art perhaps because of the lack of documentation or the complexity of a fully functional binding as implemented by Apple in Interface Builder.
My point is that there's no evidence to believe there is such a thing as a "programmatic binding" in the sense you mean. There's only a method that isn't apparently intended to be used alone, which happens to be usable as a convenience method instead of an 'addObserver:forKeyPath:...' + 'observeValueForKeyPath:...' combination. I'd contend that the latter is a superior solution because documented, although somewhat wordier to program.
>> What's wrong with:
>>
>> for (id foo in arrayController.arrangedObjects)
>> ...
>>
>> ? After all, "arrangedObjects" is documented to be an array. (It's actually a kind of proxy, but it has the behavior of an array.)
>
> Interesting. I tried this as you suggested but it results in compiler errors.
>
> error: request for member 'arrangedObjects' in something not a structure or union
> error: expression does not have a valid object type
It's objecting to the 'arrayController.arrangedObjects' syntax, which would happen if your outlet declaration was 'IBOutlet id arrayController' instead of 'IBOutlet NSArrayController* arrayController', or if your compiler version doesn't support the Obj-C 2.0 dot notation.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden