Problem loading additional frameworks in 070408 snapshot

Error and backtrace

Replying to phil:

Does using OBJC:LOAD-FRAMEWORK work ?

(It's supposed to deal with chicken-and-egg issues with respect to whether classes have to be defined before or after methods that reference them are defined, and the error seems to suggest that something's processing a method that's defined on a class that's not yet known to CLOS.)

It does, to a degree... is there a way to specify the framework directory with OBJC:LOAD-FRAMEWORK? Loading frameworks in nonstandard directories (i.e. QuartzComposer? and PDFKit) aren't working.

Replying to phil:

It possibly should do this, but there might be an argument against it. If you load the containing framework (Quartz), all of the containing frameworks get loaded as well (that'd include PDFKit and QuartzComposer?). I honestly don't know if there's a reason to insist that the subframeworks not be referenced directly (the limitation in OBJC:LOAD-FRAMEWORK isn't intentional, I just didn't think about that case), but something makes me think that other things impose a similar limitation. If I remember correctly, the linker complains if a -framework option is a subframework and not the containing ("umbrella") framework, but if I remember that correctly it might only happen in a different, unrelated context.

Replying to gb:

Sure... had I loaded the Quartz framework (oops... that fixed the problem.) It still would be useful for loading frameworks from non-standard locations (i.e. frameworks I am developing/debugging) I had implemented the framework directory as a optional via a keyword as, you are correct, for the most part you don't want to specify the path.

Apple seems to want to discourage loading "subframeworks of an umbrella framework that are not themselves umbrella frameworks."

Part of the rationale seems to be a desire to insulate software from changes, e.g., PDF functionality in the Quartz framework is currently implemented via the PDFKit subframework. If that happens to change over time, programs which use the Quartz framework will continue to work, while those that used PDFKit directly might fail. (I would imagine that the set of things loaded when you load AppKit does indeed change between releases, and that it's far better to just load AppKit (or, even better, to load Cocoa) than it is to try and guess what all of the subframeworks are and in what order they should be loaded.

In OpenMCL's case, there are additional complications. Loading a subframework (PDFKit, for example) might in fact cause the parent library and some of the siblings to be loaded (e.g., to have their classes and methods introduced into the runtime system.) When new ObjC classes are introduced into the runtime system, the bridge needs to process a (corresponding) set of interfaces to determine which classes are "public" (declared in the interfaces and integrated into CLOS) and which aren't. Instances of private, internal classes are treated as if they're instances of the innermost public superclass. If the parent framework (or a sibling) is later loaded (with a corresponding set of interfaces), the classes previously treated as private may become "public"; instances of those classes will still be treated as instances of some superclass, and that can lead to confusion.

It's certainly possible to write something that opened a subframework given a path to it and integrate it into CLOS with the guidance of a set of subframework-specific interfaces, but I think that it'd be a bad idea to do so (for reasons much like those that Apple enumerates at this link.)

The other case - loading frameworks installed in non-standard locations - seems to be worth supporting; that might be best addressed by having OBJC:LOAD-FRAMEWORK take an optional list of of framework locations (or by better documenting the fact that it does look in ~/Library/Frameworks if that directory exists.)

Thanks for the additional info and let's chalk this up to my own ignorance re: framework conventions. Since I loaded the top-level framework, everything has worked as expected.

Doh... I closed the ticket forgetting that 2nd part of this issue (loading frameworks from nonstandard locations) was still open.