[Openmcl-devel] Using Cocoa with MCL

Fri May 9 00:46:32 PDT 2003

I found the following docs on my Mac OS X system with dev tools:

file:///Developer/Documentation/Cocoa/Legacy/JavaBridge/JavaBridge.html

I didn't have time to read it though ;-)

Also, have a look at the directories /Developer/Java/Jobs and 
/Developer/Java/Headers, this is part of there autogeneration stuff, I 
think.

Sven

On Friday, May 9, 2003, at 04:57 AM, Gary Byers wrote:

>
>
> On Thu, 8 May 2003, Randall Beer wrote:
>
>>> Someone (perhaps Randall) pointed out that it's possible to peer
>>> into the ObjC runtime and find all classes; an ObjC class keeps
>>> track of its methods and their signatures, so it might be possible
>>> to automate the generation of procedural CL wrappers around
>>> everything.
>>
>> Yes, if we decide that a middle layer is best, I'm still thinking in
>> terms of generating this middle layer as automatically as possible.
>>
>>> Suppose at this procedural level it was possible to say something
>>> like:
>>>
>>> (cocoa:init (cocoa:class-alloc *nswindow-class*)
>>>                   :content-rect r	  ; details, details
>>>                   :defer nil
>>>                   :style-mask (logior ...))
>>>
>>> e.g., there's a predictable one-to-one correspondence between an
>>> ObjC method and a functional lisp interface to it (and hopefully
>>> that functional lisp interface to it looks better than my example.
>>> Some keyword arguments are elided from the example above, more
>>> to save myself some typing than because I can think of plausible
>>> defaults.)
>>>
>>> Presumably, the implementation of NSWINDOW-INSTANCE-INIT is
>>> very little more than some FFI gunk; the immediately obvious
>>> advantage of this scheme is that we don't have to read or write
>>> that FFI gunk ourselves.
>>>
>
> It might have helped if the example had used consistent naming 
> conventions.
> (See how important that is ?)
>
>>
>> It wasn't clear to me from your example whether you were thinking in
>> terms of a functional Lisp interface to ObjC or whether you were
>> thinking in terms of CLOS classes.  Specifically, what kind of thing 
>> is
>> the value of *NSWINDOW-CLASS*?
>
> Good question.  There are (maybe) around 4 possibilities:
>
> 1) A raw MACPTR to a class object, pretty much as exists now.
> 2) A raw MACPTR with some extra bits that assert that it's an ObjC
>    object (and that it's worth trying to ask ObjC what kind of
>    object it is.)  The Apple ObjC runtime allows for a lot of
>    introspection and it seems to be pretty robust and reliable;
>    if Apple keeps going in this direction, they'll eventually
>    invent lisp ...
> 3) A lisp object (with a small "o") that encapsulates the underlying
>    ObjC object in some way, but doesn't provide much OO behavior.
> 4) A fullblown CLOS object, which maybe has one of the above in a
>    slot.
>
>>
>>> Whatever the high-level solution(s) turn out to be, it doesn't seem
>>> likely that the middle layer (the functional/procedural interface)
>>> will design itself.  If the goal is to derive large parts of that
>>> middle-layer automatically, we have part of what we need (the ability
>>> to ask ObjC for all foreign method names and signatures); the part
>>> that's missing is a policy that'd guide that translation process.
>>>
>>> As an example: suppose that there's a Cocoa method that returns an
>>> :<NSR>ange structure.  The way that structure return is implemented
>>> in most C compilers is that the caller allocates a structure and
>>> passes a pointer to it as an invisble parameter to the callee; the
>>> callee just fills in its fields.  This is exposed in the FFI-based
>>> Cocoa code; would we want it to be exposed at a middle level ?  I
>>> can think of arguments pro and con, which suggests that there may
>>> be more than one level in the middle ...
>>
>> I think it should be consistent. Either we go for a layer of 
>> functional
>> syntactic sugar, which makes manipulation of ObjC objects easier and
>> more convenient (e.g., memory allocation), or we build a CLOS layer
>> which uniformly replaces ObjC objects with CLOS objects.
>
> I was thinking that for some things (very low-level event handling,
> for instance) it's desirable not to cons much, especially where nothing
> interesting's going on.  We can always use the FFI to write the
> very low-level stuff like that, and keeping the number of middle layers
> small (0 or 1) seems desirable ...
>
>
>
>> As you
>> suggest, the latter may be implemented in former.  I guess that I'm
>> struggling to clearly envision what the final goal should look like, 
>> at
>> least in broad terms.  Then we can decide what the right intermediate
>> layers of abstraction might be.  Is the goal (1) Lisp sugar for ObjC,
>> (2) CLOSified Cocoa, (3) an MCL-like CLOS system, (4) something like
>> CLIM (or (5), something I haven't thought of)?
>
> What I'm thinking of as "the middle layer" might also be described
> as (1).  I think that it'd be a step up from the status quo; it'd
> make things like the demo IDE easier to write and (hopefully) easier
> for people to understand.  I don't know that CLOS needs to be too
> involved in things at this level.  This layer might wind up being
> similar to CLX or XLib in scope: it's possible to program in it,
> but it's also useful as a foundation for higher-level things (McCLIM
> and other things use CLX, GTK/GDK/GNOME and Qt/KDE use XLib.)
>
> One place where that analogy breaks down is that CLX and traditional
> Carbon are "toolkits", whereas Cocoa (and modern Carbon, to a lesser
> extent) are "frameworks" : the toolkits provide drawing primitives
> and event notification, while the frameworks additionally provide
> reasonable default behavior and a protocol for extending it.
>
> In something like MCL's window system, CLOS provides the framework
> on top of the Carbon toolkit.  What would/should CLOS provide for
> Cocoa ?
>
>>
>> Randy
>>
>>
>>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>
--
Sven Van Caekenberghe - mailto:sven at beta9.be
Beta Nine - software engineering - http://www.beta9.be
.Mac - svc at mac.com - http://homepage.mac.com/svc

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel