[Openmcl-devel] Three questions

[Gary Byers]

On Fri, 8 Feb 2008, Andrew Shalit wrote:

>
> On Feb 8, 2008, at 5:34 PM, R. Matthew Emerson wrote:
>
>>
>> On Feb 8, 2008, at 4:34 PM, Ron Garret wrote:
>>
>>> 1.  Is there a way to tell when a window has been closed?
>>
>> I only know of the usual Cocoa/Objective-C ways:
>>   * register to receive NSWindowWillCloseNotification
>>   * implement windowWillClose: in the window's delegate
>
> This is a good example of the kind of thing that I think works better
> in MCL, which builds a clean Lisp layer on top of the native Mac OS
> libraries, rather than just providing a thin Lisp interface for
> directly programming the Mac OS libraries.

I'd forgotten that there were no memory management problems with (or
limitations to) MCL's approach.  Ah, truly that was a Golden Age ...
why exactly did it seem like such a mess some of the time ?  (If I
knew where to find them, I'd suggest that the bug-mcl archives
be required reading for anyone interested in this issue.)

>
> Behaviors like the one Matthew describes should be defined by
> default.  There's no reason to require each CCL programmer to reinvent
> this wheel, and there's no reason programmers should have to keep
> track of things by hand that can be tracked automatically.  If we
> wanted to keep track of things by hand, we wouldn't be programming in
> Lisp.
>
> I hope that as we continue to work on the CCL Cocoa libraries, they
> can become a little bit thicker, and take care of these sorts of
> things themselves.


One step in that direction might involve thinking of the original
question as two separate questions (not counting subquestions ...)

1) Is there a way to tell if an ObjC object has been deallocated ?
(Subquestion: barring that, is there a way to make that a meaningless
question, in the same sense that it's impossible to talk about
a lisp object having been "deallocated" ?  Obviously, lisp objects
get deallocated (GCed) all the time, but

2) If we avoid talking about deallocated NSWindow objects and given
each of several plausible definitions of "closed" (not visible,
not visibile but has been, not visible and can't  be made visible
anymore ...), are there ways of asking if an NSWindow is closed ?
(Subquestion: in the interim, should people who don't want windows
to be released when closed be encouraged to

MCL didn't solve the problem of how to determine whether or not a
window was closed: it solved the problem of whether or not a "closed"
flag in an encapsulating object was set.  If all ways of closing a
window went through methods on that encapsulating object, the flag
would be set and that was often good enough.  Once in a while, the
encapsulating object and the underlying window object got out of
synch, but since this we're discussing how MCL Got This Right in The
Golden Age we can ignore hundreds or thousands of messages to 
bug-mcl over a couple of decades that were under the impression that
that approach wasn't perfect either.

If the question has something to do with arguing the relative merits
of the MCL-like encapsulation vs "treat Cocoa objects as first-class
objects, even though that doesn't always work" ... well, since both
approaches fail sometimes, it's hard to know which is better.  If the
question is "is MCL-like encapsulation better than treating Cocoa
obects like fairly high-level first-class objects" and they indeed are
(GC-wise), then I think it's much closer to "which way is forward ?",
and I'm always surprised to see disagreement about that.

Personally, I'd much rather say "it's often naive to hold strong
global references to windows, since that keeps them from being GCed",
rather than saying "don't do that, since you'll be disappointed when
ObjC deallocates the object behind your back."