[Openmcl-devel] Three questions

[Ron Garret]

On Feb 9, 2008, at 2:56 AM, Gary Byers wrote:

> ? (#/setReleasedWhenClosed: *w* nil)

Ah!  There's a handy-dandy little trick!  (My approach to learning  
Cocoa has been to get things to work first and worry about memory  
management issues later.)  I'm surprised that's not the default.

> Speaking of The Undead: one traditional OSX debugging technique which
> is used for both Cocoa and Core Foundation programming is to enable
> "Zombie" objects

And another one.  Thanks!

> As you noted, after *w* has been released:
>
> ? (type-of *w*)
> NS:NS-WINDOW
>
> which is wrong.

Yes, but at least part of CCL knows it's wrong, because *w* now PRINTS  
as a "bogus object" (even if type-of doesn't seem to be aware of it).

> Anyway ... is it a good thing that people doing Cocoa programming in
> CCL have to occasionally be aware of this sort of thing ?  Of course
> not.  I think that we all agree that this sort of thing shouldn't be
> exposed to the user but there are differences of opinion about how
> that should best be achieved.  I doubt that anyone would disagree that
> better-integrating ObjC and Lisp memory management would be a Good
> Thing (that would incidentally make this problem go away, to be
> replaced with the "why is this guy holding on to NSWindow objects -
> keeping them from being GCed - so long?" problem).  I have difficulty
> reaching the conclusion that the fact that this integration doesn't
> exist somehow makes MCL-like encapsulation a good idea; there seems to
> be too much evidence to the contrary.

I'm not entirely sure what you mean by MCL-like encapsulation, and I'm  
also not sure I agree with you that it would necessarily be a good  
thing for Cocoa programmers to not have to worry about memory  
management.  Certainly that would be a good thing all else being  
equal, but all else is rarely equal.  Personally, I'd rather have a  
usable kludge now than a perfect solution three years from now (where  
by "usable" I mean that there might be some constraints I have to  
follow to in order to avoid errors, but nothing that I would do in the  
normal course of events (like closing a window) should make the  
application crash).

rg