[Openmcl-devel] Deploying Cocoa Apps

[Gary Byers]

On Thu, 2 Mar 2006, Joel Reymont wrote:

> I have 1.0 but I still see the WebKit example using map-objc-classes
> and install-foreign-objc-class. I don't see any parsing of header files.

The parsing of header files happened several months ago, and as far as
I know I was the only one who saw it.

The results of that parsing are in "ccl:darwin-headers;webkit;*.cdb".

Since the bridge gets method and class declarations from those .cdb
files, it's necessary to produce that information for other add-on
frameworks.

>
> BTW, was there anything wrong with skipping methods that, say, start
> with _ (internal) upon import and resolving method pointers and the
> like upon instantiation of the CLOS wrapper?
>

Not all methods that are undocumented, internal, and may appear,
disappear, or have their signatures change between releases have names
that start with underscores.

In the environment that  I  just looked at, there are roughly 1000
ObjC classes defined.  The header files describe a little fewer than
300 of them

> Also, developers themselves could have control over what to pre-
> import and what methods to use from the Cocoa API. If someone uses
> bits that are private and they don't exist in the deployed Cocoa
> version that it's no a fault of the bridge.

It's possible to say (DECLARE-OBJC-CLASS) and (DECLARE-OBJC-METHOD);
at one point (for reasons that I don't quite remember) it was necessary
to do this for some internal classes.  (I think that SEND did runtime
dispatching based on the (ObjC) class of the receiver, and got confused
if that was an internal, undeclared class.)

There are certainly ObjC classes that are undeclared (not mentioned in
any public header file), widely used, and unlikely to disappear anytime
soon.  (NSCFString comes to mind.)

? (ccl::%make-nsstring "Hello")
#<NS-MUTABLE-STRING "Hello" (#x1FA300)>
? (ccl::objc-class-name *)
"NSCFString"

Ideally, if you wanted to believe that NSCFString was a real, first-class
class, you could do:

? (ccl::declare-objc-class ns::ns-cf-string ns:ns-mutable-string)
NS:NS-CF-STRING

and a subsequent:

? (%make-nsstring "Hello")

would claim that the result was indeed an instance of NS:NS-CF-STRING.
(That doesn't work as I'd have expected, and it may or may not be
"ideal" for that sort of change to the declared class hierarchy to
happen at runtime.)  It's a little more tractable (and happens to
also work) if that declaration's made before the bridge first processes
the Cocoa classes and the declarations that come from the interfaces.

I agree that the case where a user (developer) declares and uses
private classes or methods that don't exist in a different runtime
environment is not something that the bridge needs to worry about
(that couldn't work in an ObjC program, either.)  I do think that
you ultimately need some declarative information in order to even partly
determine whether differences between runtime environments are likely
to be significant, and the header files are an obvious and good source
of that information.  (In some cases, information that originally came
from the header files is  more accurate and complete than the information
that's available via introspection.)

>
> Anyway, this is the approach that I'm taking in my Cocoa bridge for
> Allegro.
>
> 	Joel
>
> On Mar 2, 2006, at 10:30 AM, Gary Byers wrote:
>
>> The WebKit example seemed to work out of the box.
>>
>> A little while after 1.0 was released, someone asked how they'd go
>> about using another add-on (AddressBook ?).  I said something like
>> "just do what WebKit does"; a little while later, they replied saying
>> that they'd done what the WebKit example does (run the header files
>> through the interface translator and tell the Cocoa Bridge to use
>> those translated interfaces while opening the appropriate framework
>> bundles) and things weren't working (no CLOS metainformation existed
>> for the AddressBook classes.)
>
> --
> http://wagerlabs.com/
>
>
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>