@ssp: I would have thought that the value of 'myImage' doesn't really change in the process of this lazy loading and thus observers shouldn't been notified.
When the parent object is initialized, the value is nil. When the value is the lazily loaded, it becomes non-nil. So yes, the value is changing and I personally think KVO should know about it because otherwise you could end up with empty views and other confusing behavior.
(I find it hard to cram all of Apple into your anti-spam text field - not even the symbol will work ;)
"Apple" is all the input box is looking for. :)
@Scott Guelich: If you hadn't been loading that value "lazily", no KVO notification would be sent because the image would have been initialized during the enclosing object's initialization -- before any KVO observers could have possibly started watching it.
In my opinion, you should always try to honor the KVO contract, even if there's no obvious need to do so. It keeps things more predictable, particularly as the application changes. Consider this:
A couple of things could happen here. If the data is always the same when loaded from disk, then this will work fine, but mostly by accident. If the image loaded from disk is not always the same, the new image will only be picked up if I've honored the KVO contract by sending out notifications even when I thought I didn't need to. If I don't honor the contract, then the bound objects will have incorrect data.
Sending a notification when it gets set later seems to be exposing an internal implementation detail.
No, it's being truthful about what's happening. The image object is changing, it's just that some might think the change is insignificant. Hiding that event is (in my opinion) is depending too much on a current behavior which could change later, causing hours of debugging.
Furthermore, if setMyImage: is public then your interface allowing another object to override the default image
I admit this is not a perfect example, it was just the most obvious one I could come up with.
by Scott Stevenson — Jun 17
When the parent object is initialized, the value is nil. When the value is the lazily loaded, it becomes non-nil. So yes, the value is changing and I personally think KVO should know about it because otherwise you could end up with empty views and other confusing behavior.
(I find it hard to cram all of Apple into your anti-spam text field - not even the symbol will work ;)
"Apple" is all the input box is looking for. :)
@Scott Guelich: If you hadn't been loading that value "lazily", no KVO notification would be sent because the image would have been initialized during the enclosing object's initialization -- before any KVO observers could have possibly started watching it.
In my opinion, you should always try to honor the KVO contract, even if there's no obvious need to do so. It keeps things more predictable, particularly as the application changes. Consider this:
MyClass* myObject = [[MyClass alloc] init]; NSImage* currentImage = [myObject myImage]; [myObject setMyImage:nil]; currentImage = [myObject myImage];A couple of things could happen here. If the data is always the same when loaded from disk, then this will work fine, but mostly by accident. If the image loaded from disk is not always the same, the new image will only be picked up if I've honored the KVO contract by sending out notifications even when I thought I didn't need to. If I don't honor the contract, then the bound objects will have incorrect data.
Sending a notification when it gets set later seems to be exposing an internal implementation detail.
No, it's being truthful about what's happening. The image object is changing, it's just that some might think the change is insignificant. Hiding that event is (in my opinion) is depending too much on a current behavior which could change later, causing hours of debugging.
Furthermore, if setMyImage: is public then your interface allowing another object to override the default image
I admit this is not a perfect example, it was just the most obvious one I could come up with.