Re: Removing the Filename flag in Doc. based Application

2008-05-27 Thread Mark Piccirelli
There's some advice about this in the "Advice for Overriders of - 
[NSDocument displayName]" section of the AppKit release notes at http://developer.apple.com/releasenotes/Cocoa/AppKit.html. 
 (Searching for "advice" on that page turns up a couple of other  
tidbits too.)


-- Mark

On May 24, 2008, at 1:02 AM, Caleb Strockbine wrote:


On May 23, 2008, at 2:51 PM, [EMAIL PROTECTED] wrote:

How do I set my document based application to omit the filename  
reference at

the top of each opened document window?


Kyle Sluder's explanation is quite informative, but it may also be  
more complicated than you need. If you really just want to change  
the name of your document, you can override -[NSDocument  
displayName] like this:


// Adding this method to your document subclass will cause the
// title of every document window to be "Foo".
- (NSString *)displayName
{
   return @"Foo";
}


If you want to also remove the file proxy icon (small icon next to  
the window title), you'll likely want to create a custom window  
controller as described by Kyle and implement either the - 
windowDidLoad: or -awakeFromNib methods such that you get a  
reference to the icon button and send it a -setHidden: message, like  
this:


// Put the following in your custom window controller where it'll
// be executed soon after the window is loaded.
NSButton *fileButton =
   [window standardWindowButton:NSWindowDocumentIconButton];
if (fileButton != nil) {
   [fileButton setHidden:YES];
}

The reason for putting the code above in a custom window controller  
is that ideally, your document class shouldn't be in the business of  
defining what the window should look like. The window controller is  
a better place for that.


cheers,

Caleb Strockbine
___

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/markp%40apple.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]


Re: KVO strangeness under 10.5

2008-04-12 Thread Mark Piccirelli
You can copy-and-paste to find out what the surprising observers are,  
as in:


(gdb) po 0x19e5a0

-- Mark

On Apr 12, 2008, at 2:59 PM, Sean Todd wrote:
I have a Cocoa document app that uses bindings. After installing  
10.5 and Xcode 3.0, I started seeing console output stating that  
objects were being deallocated while observers are still registered  
with them. After some investigation, I found that the objects being  
deallocated had an extra observer that I never registered (see the  
final observance instance listed in the -observationInfo output below:


(gdb) po [theItem observationInfo]
 (
Options:  Context: 0x0, Property:  
0x19e5c0>
category, Options:  Context: 0x0,  
Property: 0x1a3c80>
Options:  Context: 0x0, Property:  
0x192920>
isDropped, Options:  Context: 0x0,  
Property: 0x1a3cd0>
Options:  Context: 0x0, Property:  
0x192920>
grade, Options:  Context: 0x18ea60,  
Property: 0x192920>

)

I have no idea what sort of object 0x6503f00 is or how/when it was  
registered. Looking at the address in memory did not give me any  
clues. The one interesting bit of info is that the address listed  
with its Context is the same as the first 4 observers.


Continuing on predictably leads to the console output:

2008-04-12 16:18:20.760 MyApp[329:813] An instance 0x1c3d40 of class  
Assignment is being deallocated while key value observers are still  
registered with it. Observation info is being leaked, and may even  
become mistakenly attached to some other object. Set a breakpoint on  
NSKVODeallocateBreak to stop here in the debugger. Here's the  
current observation info:

 (
grade, Options:  Context: 0x1c3ce0,  
Property: 0x192920>

)


When I debug this app with Xcode 2.4 on 10.4.x, there are no extra  
observers and everything works well.


I did not see anything addressing this issue in the foundation  
release notes. Nor have I found any discussion of this problem in  
the archives. Am I missing something? Do I need to file a bug? Any  
help would be appreciated.

___

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/markp%40apple.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]


Re: KVO strangeness under 10.5

2008-04-12 Thread Mark Piccirelli
Yikes, that's not good. I'd try running with NSZombieEnable = YES to  
see if that turns up anything. That should also set  
NSDeallocateZombies = NO, which might make gdb po work.


-- Mark

On Apr 12, 2008, at 5:14 PM, Sean Todd wrote:


Unfortunately, that doesn't work:

grade, Options:  Context: 0x1957c0,  
Property: 0x18edf0>

)
(gdb) po 0x6500210

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xc007391b
0xfffeff18 in objc_msgSend_rtp ()
The program being debugged was signaled while in a function called  
from GDB.

GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off"
Evaluation of the expression containing the function  
(_NSPrintForDebugger) will be abandoned.



On Apr 12, 2008, at 5:18 PM, Mark Piccirelli wrote:
You can copy-and-paste to find out what the surprising observers  
are, as in:


(gdb) po 0x19e5a0

-- Mark

On Apr 12, 2008, at 2:59 PM, Sean Todd wrote:
I have a Cocoa document app that uses bindings. After installing  
10.5 and Xcode 3.0, I started seeing console output stating that  
objects were being deallocated while observers are still  
registered with them. After some investigation, I found that the  
objects being deallocated had an extra observer that I never  
registered (see the final observance instance listed in the - 
observationInfo output below:


(gdb) po [theItem observationInfo]
 (
name, Options:  Context: 0x0,  
Property: 0x19e5c0>
category, Options:  Context: 0x0,  
Property: 0x1a3c80>
grade, Options:  Context: 0x0,  
Property: 0x192920>
isDropped, Options:  Context: 0x0,  
Property: 0x1a3cd0>
grade, Options:  Context: 0x0,  
Property: 0x192920>
grade, Options:  Context: 0x18ea60,  
Property: 0x192920>

)

I have no idea what sort of object 0x6503f00 is or how/when it was  
registered. Looking at the address in memory did not give me any  
clues. The one interesting bit of info is that the address listed  
with its Context is the same as the first 4 observers.


Continuing on predictably leads to the console output:

2008-04-12 16:18:20.760 MyApp[329:813] An instance 0x1c3d40 of  
class Assignment is being deallocated while key value observers  
are still registered with it. Observation info is being leaked,  
and may even become mistakenly attached to some other object. Set  
a breakpoint on NSKVODeallocateBreak to stop here in the debugger.  
Here's the current observation info:

 (
grade, Options:  Context: 0x1c3ce0,  
Property: 0x192920>

)


When I debug this app with Xcode 2.4 on 10.4.x, there are no extra  
observers and everything works well.


I did not see anything addressing this issue in the foundation  
release notes. Nor have I found any discussion of this problem in  
the archives. Am I missing something? Do I need to file a bug? Any  
help would be appreciated.

___

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/markp%40apple.com

This email sent to [EMAIL PROTECTED]






___

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 [EMAIL PROTECTED]


Re: KVO strangeness under 10.5

2008-04-13 Thread Mark Piccirelli

Sean --

Nothing in KVO's guts registers arrays as observers, and nothing in  
Cocoa Bindings either as far as I know.


For the curious, NSKeyValueObservances are instances of an internal  
class that gets instantiated and put in the observation info of  
observed object. (Hugely subject to change; no one should write apps  
that depend on these details.) In 10.5 they are also used as observers  
when key paths are being observed. For example, the observance for an  
object's "category.color" is itself an observer of the "color" of the  
object's current "category" and forwards notifications to the ultimate  
observer. When the object's "category" changes it also removes itself  
as an observer the old value's "color" and adds itself as an observer  
of the new value before sending the notification to the ultimate  
observer. So, it makes sense that you're seeing NSKeyValueObservances  
as observers.


One possible cause of what you're seeing might be bad KVO-compliance  
for "category." If KVO itself doesn't get notified of changes to that  
value the machinery just described gets pretty confused. There are  
exceptions thrown for many instances of that mistake but perhaps not  
all.


Anyway, an app that works on 10.4 but not on 10.5 always smells like a  
backward binary incompatibility in our stuff regardless of where the  
actual programming mistake is. Please file a bug report with  
instructions on how to reproduce this problem. Hopefully your app is  
something you can attach or point us to. Thanks…


-- Mark

On Apr 13, 2008, at 1:35 PM, Sean Todd wrote:

Thanks Mark (and Jim) for the NSZombieEnabled/NSDeallocateZombies  
reminder. This showed me that the object has indeed been deallocated  
by the time that breakpoint was reached.


Setting an earlier breakpoint I was able to get some more  
information on this unknown observer:


grade, Options:  Context: 0x1e00b0,  
Property: 0x1e1040>

)
(gdb) po 0x620c180
(
Options:  Context: 0x1e6450, Property:  
0x1e2ca0>

)

So this object is some array that contains single  
NSKeyValueObservance. Following the trail of observers shows:


(gdb) po 0x182180
category.color, Options:  Context: 0x0,  
Property: 0x62059d0>

(gdb) po 0x62005f0
{object: ,  
bindings: content=arrangedObjects,  
selectionIndexes=selectionIndexes, sortDescriptors=sortDescriptors}


Unfortunately, I am still puzzled by how/why this array is set as an  
observer.


Setting a breakpoint with -addObserver:... (as suggested by Chuck  
Steinman) did not help as gdb could not provide any data via info  
args when this breakpoint was hit.


I am sure that this is due to changes in the KVO system in 10.5 but  
not sure if this is revealing a bug in that system or uncovering a  
problem with my use of KVO (perhaps some workaround code to a  
problem with KVO and bindings pre-10.5).



On Apr 12, 2008, at 7:42 PM, Mark Piccirelli wrote:
Yikes, that's not good. I'd try running with NSZombieEnable = YES  
to see if that turns up anything. That should also set  
NSDeallocateZombies = NO, which might make gdb po work.


-- Mark

On Apr 12, 2008, at 5:14 PM, Sean Todd wrote:

Unfortunately, that doesn't work:

grade, Options:  Context: 0x1957c0,  
Property: 0x18edf0>

)
(gdb) po 0x6500210

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xc007391b
0xfffeff18 in objc_msgSend_rtp ()
The program being debugged was signaled while in a function called  
from GDB.

GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off"
Evaluation of the expression containing the function  
(_NSPrintForDebugger) will be abandoned.



On Apr 12, 2008, at 5:18 PM, Mark Piccirelli wrote:
You can copy-and-paste to find out what the surprising observers  
are, as in:


(gdb) po 0x19e5a0

-- Mark

On Apr 12, 2008, at 2:59 PM, Sean Todd wrote:
I have a Cocoa document app that uses bindings. After installing  
10.5 and Xcode 3.0, I started seeing console output stating that  
objects were being deallocated while observers are still  
registered with them. After some investigation, I found that the  
objects being deallocated had an extra observer that I never  
registered (see the final observance instance listed in the - 
observationInfo output below:


(gdb) po [theItem observationInfo]
 (
name, Options:  Context: 0x0,  
Property: 0x19e5c0>
category, Options:  Context: 0x0,  
Property: 0x1a3c80>
grade, Options:  Context: 0x0,  
Property: 0x192920>
isDropped, Options:  Context: 0x0,  
Property: 0x1a3cd0>
grade, Options:  Context: 0x0,  
Property: 0x192920>
grade, Options:  Context: 0x18ea60,  
Property: 0x192920>

)

I have no idea what sort of object 0x6503f00 is 

Re: Cannot Remove Observer Error

2008-04-15 Thread Mark Piccirelli
How are KVO notifications for the Wine class' wineType property being  
done? KVO is complaining that not enough of them are being sent out.  
The rule for KVO-compliance in this case is that something must do  
[wine willChangeValueForKey:@"wineType"] before the value returned by  
[wine valueForKey:@"wineType"] would change and then something must  
invoke [wine didChangeValueForKey:@"wineType"] after the value  
returned by [wine valueForKey:@"wineType"] has changed. Automatic KVO  
notification does that, but only for changes done with [wine  
setWineType:aWineType], if there is such a method, or [wine  
setValue:aWineType forKey:@"wineType"]. If the wine type is stored in  
an instance variable and something changes the value of that ivar  
without doing -willChangeValueForKey:/-didChangeValueForKey: you'll  
get this exception.


What changed in your app? One guess is that nothing was observing any  
Wine's "wineType.name" before but you're now doing something different  
with Cocoa Bindings that is causing it to be observed.


-- Mark

On Apr 14, 2008, at 6:12 PM, Thaddeus Cooper wrote:
Starting earlier today, I started getting the following error in my  
software.


2008-04-14 17:59:41.535 WineCellar[4928:10b] Cannot remove an  
observer  for the key path "wineType.name 
" from , most likely because the value for the key  
"wineType" has changed without an appropriate KVO notification being  
sent. Check the KVO-compliance of the Wine class.


I haven't changed anything significant (well at least I don't think  
I did) and I definitely have not been messing around with the  
WineArrayController and/or the Wine classes. I can't figure out how  
to track this error down -- I've tried a number of things including  
putting a removeObserver:forKeyPath method in the array controller  
so I could look at the back trace and I've also put in enter and  
exit debug messages in a large portion of the code. Still the error  
seems to come from nowhere and I am stumped as to how I might find  
what the root cause of the problem is.


Does anyone have any suggestions as to how to track down this type  
of error.


Thanks very much.

Thaddeus O. Cooper
([EMAIL PROTECTED])



___

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/markp%40apple.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]


Re: AppleScript - occasional crashes on Leopard

2008-04-22 Thread Mark Piccirelli

Is this a garbage-collected app? If so the crash is a known bug.

-- Mark

On Apr 22, 2008, at 10:47 AM, Steve Cronin wrote:

Folks;

I've seen some inconsistent behavior on AppleScript running under  
Leopard.


Here's an example:
...
NSString *theScript =@"some valid dynamic script text"
NSDictionary *errorDict = [NSDictionary dictionary];
	NSAppleScript *appleScriptObject = [[NSAppleScript alloc]  
initWithSource:theScript];	
	NSAppleEventDescriptor *eventDescriptor = [appleScriptObject  
executeAndReturnError: &errorDict];

...

will OCCASIONALLY crash at the NSAppleEventDescriptor specification:

#0  0x932c3d5c in getDescDataType
#1  0x932c7ab7 in aeCoerceDescInternal
#2  0x932cc055 in AECoerceDesc
#3  0x1d4a8150 in ComponentCoerceDesc
#4  0x1d48cbec in ASCompile
#5  0x903bacb8 in CallComponentFunction
#6  0x1d487ae2 in AppleScriptComponent
#7  0x1d4a3927 in AGenericManager::HandleOSACall
#8  0x903755cd in CallComponentDispatch
#9  0x953fc513 in OSACompile
#10 0x93e6edaf in -[NSAppleScript compileAndReturnError:]
#11	0x93e6f096 in -[NSAppleScript(NSPrivate)  
_executeWithMode:andReturnError:]

#12 0x93e6ee51 in -[NSAppleScript executeAndReturnError:]

Is there a new/better means in Leopard of accomplishing the  
execution of dynamic scripts?
NO the crash is NOT related to the validity of the script, of this I  
am absolutely certain!  (It only crashes sometimes using the same  
resulting script!!)

Is a dual processor Intel creating a risk here?
Is there something better I can do to handle the error?
Why should I have to use a @try block here?
I thought that was what the executeAndReturnError  parameter was  
for!!  But I don't get a chance to examine the errorDict.


It will crash only every so often
My hunch is that crashes are more likely when machine is under load  
and memory swapping might be involved.

This is running on a 4G MacBook...

Any wisdom appreciated!
Steve
___

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/markp%40apple.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]


Re: AppleScript - occasional crashes on Leopard

2008-04-22 Thread Mark Piccirelli
Yes. But we intend to fix it in a software update. (And I can't say  
anything more specific than that. A fix isn't a fix until it's shipped.)


-- Mark

On Apr 22, 2008, at 1:01 PM, Michael Watson wrote:


Mark,

So GC + NSAppleScript == avoid for now?


--
m-s

On 22 Apr, 2008, at 15:53, Mark Piccirelli wrote:

Is this a garbage-collected app? If so the crash is a known bug.

-- Mark

On Apr 22, 2008, at 10:47 AM, Steve Cronin wrote:

Folks;

I've seen some inconsistent behavior on AppleScript running under  
Leopard.


Here's an example:
...
NSString *theScript =@"some valid dynamic script text"
NSDictionary *errorDict = [NSDictionary dictionary];
	NSAppleScript *appleScriptObject = [[NSAppleScript alloc]  
initWithSource:theScript];	
	NSAppleEventDescriptor *eventDescriptor = [appleScriptObject  
executeAndReturnError: &errorDict];

...

will OCCASIONALLY crash at the NSAppleEventDescriptor specification:

#0  0x932c3d5c in getDescDataType
#1  0x932c7ab7 in aeCoerceDescInternal
#2  0x932cc055 in AECoerceDesc
#3  0x1d4a8150 in ComponentCoerceDesc
#4  0x1d48cbec in ASCompile
#5  0x903bacb8 in CallComponentFunction
#6  0x1d487ae2 in AppleScriptComponent
#7  0x1d4a3927 in AGenericManager::HandleOSACall
#8  0x903755cd in CallComponentDispatch
#9  0x953fc513 in OSACompile
#10 0x93e6edaf in -[NSAppleScript compileAndReturnError:]
#11	0x93e6f096 in -[NSAppleScript(NSPrivate)  
_executeWithMode:andReturnError:]

#12 0x93e6ee51 in -[NSAppleScript executeAndReturnError:]

Is there a new/better means in Leopard of accomplishing the  
execution of dynamic scripts?
NO the crash is NOT related to the validity of the script, of this  
I am absolutely certain!  (It only crashes sometimes using the  
same resulting script!!)

Is a dual processor Intel creating a risk here?
Is there something better I can do to handle the error?
Why should I have to use a @try block here?
I thought that was what the executeAndReturnError  parameter was  
for!!  But I don't get a chance to examine the errorDict.


It will crash only every so often
My hunch is that crashes are more likely when machine is under  
load and memory swapping might be involved.

This is running on a 4G MacBook...

Any wisdom appreciated!
Steve
___

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/markp%40apple.com

This email sent to [EMAIL PROTECTED]


___

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/mikey-san%40bungie.org

This email sent to [EMAIL PROTECTED]




___

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 [EMAIL PROTECTED]


Re: Observing with GC

2008-02-26 Thread Mark Piccirelli

On Feb 26, 2008, at 2:36 PM, Graham wrote:

I hesitate to weigh in on an established thread, but I ran into this  
myself a while back.


Isn't part of the purpose of the observer mechanism to allow  
observees to proceed with their normal activities blissfully unaware  
of any observers that might be looking at 'em?


Yes. As long as an object's class is properly KVO-compliant for a  
property you, as the author of that class, shouldn't have to care even  
a little bit about what other objects are observing that property.


In which case they won't be keeping track of their observers so have  
no easy way to tell them to get lost when they are about to disappear.




Obviously one can design observees to keep a reference to their  
observers, but if they need to do that they may as well message them  
directly with state changes (though KVO as it stands is obviously  
still more convenient).


Right. In general observed objects being destroyed should never try to  
shrug off their observers and shouldn't have to. There are a few  
reasonable uses for objects observing themselves, and such objects  
have to stop observing themselves at some point during their  
lifecycle, but I've never seen code like [self  
removeObserver:someObjectOtherThanSelf forKeyPath:aKeyPath] that  
couldn't be improved upon.


I've probably misunderstood something about the design philosophy  
behind KVO, but as everything is up to the observer to decide when  
to safely start and stop observing, the possibility of the observee  
being dealloced out from underneath the observer is a realistic  
possibility that the current design doesn't handle very nicely.  
Surely it would be more useful and easier to use if the pattern was  
for an observer to observe an object until it decides to stop OR  
UNTIL the observee goes away, whichever occurs first. I don't  
understand why this second case has to cause an error, as it does now.


Perhaps someone better acquainted with the design can explain why  
it's not done this way? Working around this one issue vastly  
overcomplicates an observer/observee situation which to my mind  
makes KVO less useful than it appears to be.


Situations in which the observee goes away before the observer are  
always pretty fishy, and we'll probably never support them. Observers  
in general should start observing in response to some event and stop  
observing in response to the inverse event. In between something  
should be retaining (or strongly referencing, in GC land) the  
observee, if only so the observer can stop observing it properly and  
not make KVO itself leak memory. In Leopard Sketch for example an  
SKTGraphicView starts observing SKTGraphics when its "graphics"  
property is bound and stops observing them when the property is  
unbound. In between it also starts observing SKTGraphics when they're  
added to the bound-to to-many relationship and stops observing them  
when they're removed. (SKTGraphicView is doing two levels of  
observation here; see the source code.) Pretty straightforward  
balancing in both cases. There's no possibility of SKTGraphics being  
deallocated out from under the observing SKTGraphicView because they  
should be being retained by the array that is the value of the bound- 
to to-many relationship, an SKTDocument's "graphics" in the case of  
Sketch, anyway.


In this example, an SKTGraphic being deallocated while something's  
observing it would be symptomatic of either:
• Something that's not really a memory leak but might as well be. An  
SKTGraphicView could probably get away with not removing itself as an  
observer of SKTGraphics as they're removed from the bound-to  
relationship, but the memory that the KVO machinery allocated when the  
SKTGraphicView was added as an observer to the SKTGraphic would never  
get deallocated. Even if we (Apple) had just made KVO silently  
deallocate that memory when the observee was deallocated it would have  
been a waste of memory in the meantime. A potentially large one in  
this example, taking into account that many SKTGraphics might be  
extant but no longer visible in an SKTGraphicView because of stuff  
like undo support.
• Something bad like faulty KVO-compliance for "graphics" in  
SKTDocument resulting in the SKTGraphicView not being notified that it  
should stop observing individual SKTGraphics.


These sorts of problems are why KVO, in non-GC'ed apps anyway, logs so  
crabbily about objects being deallocated while observed. In every case  
where the logging happens there was always a moment before that when  
the observing should have stopped.


In GC land KVO still has the same requirement that every invocation of  
-addObserver:… is balanced by an invocation of -removeObserver:… This  
is bad and we know it. The "inverse event" mentioned up above is easy  
to make happen when every significant observer has a -dealloc method  
anyway. -[SKTGraphicView dealloc] for example does the unbinding  
mentioned a