[Openmcl-devel] Events, Windows, and OpenMCL

[Gary Byers]

On Sun, 10 Dec 2006, Brent Fulgham wrote:

> Speaking of the Cocoa bindings:
>
> 1.  Do all child classes of things derived from NS:NS-OBJECT have to be 
> declared as members of the NS:+NS-OBJECT meta-class?

Yes.  There are two axes involved when one defines a class:

1) one describes inheritance relationships that apply to instances.
A BINARY-FILE-STREAM is a FILE-STREAM and therefore also a STREAM.
The superclasses specified in a DEFCLASS form specify these
relationships.

2) the other - not used as often - describes inheritance relationships
that apply to the class itself.  In most cases, CLASS objects are
just "instances of the class whose name is STANDARD-CLASS"; when
defining an ObjC class, we want the class object to something that
the ObjC runtime can use directly.

In contrast to CLOS classes (which usually inherit from one of
a small number of CLASS metaobjects), ObjC classes typically
have their own unique metaclasses, but this unique metaclass
is usually created at the same time that the class object is.
Using (:metaclass ns:+ns-object) is kind of a hack to work
around the fact that the -real- metaclass doesn't exist yet.

The AMOP says that the :METACLASS option to ENSURE-CLASS defaults to
STANDARD-CLASS.  It might arguably have been better to make it default
to something based on the metaclasses of the superclass arguments
or something, though that may be harder to do in general than it
might seem at first clance.  (The :metaclass option already controls
how the superclasses default, so there's a slippery slope there.)

>
> 2.  Is there any reason the "Cocoa" framework (which works quite nicely for 
> creating windows from the console) is still part of "examples", rather than 
> part of the main system image?  It's really quite nice.

It started out as an example, and not enough work has been done on it
in the last few years to really justify moving it elsewhere.  (This is
of course circular, since some of the work that needs to be done is to
simply move it elsewhere.)

Over much of that few years of underactivity, I've said "I hope that
it'll soon be possible to move forward with both the bridge/framework
and the proof-of-concept-but-not-too-usable demo IDE."  Rather than
repeat that, I think that I'd rather say:

1) Clozure refuses to be held legally responsible for any unfortunate
    breath- holding incidents.  (E.g., don't hold your breath.)  But

2) Stay tuned.

>
> Thanks,
>
> -Brent
>