[Openmcl-devel] Resolving calls to methods with ambiguous return types

[Phil]

On Sep 18, 2006, at 6:35 PM, Gary Byers wrote:
> Could you remind me/the list of the context in which you're trying  
> to deal
> with ambiguous return types ? (E.g., is SEND having trouble with them,
> or is the difficulty elsewhere ?)

Sorry... yes, it's the problem with send/slet having difficulty  
determining what is being returned by method calls which are  
determined to be ambiguous as a result of multiple methods having the  
same name but have different return types.  As you suggested, it is  
for the more generic methods such as size, display, etc. and  
therefore the bridge doesn't know how to handle them as it appears to  
be using the method name alone to determine the return type which  
isn't enough in these cases.

On Aug 13, you summarized it as follows:

> As near as I can tell, you've introduced a declaration for a "display"
> method on a class named "DOMCSSStyleDeclaration" (presumably by  
> loading
> WebKit.)  Unlike the "display" methods on NSWindow and NSView that
> the bridge already knows about - which return :VOID - the "display"
> method on DOMCSSStyleDeclaration returns an NSString.  In order to
> compile (SEND x 'display), the bridge needs to know whether X
> is a DOMCSSStyleDeclaration or something else.
>
> As I tried to explain in a reply to someone else a few days ago, the
> code used by the WebKit example to make the classes defined in an
> add-on/framework library like WebKit doesn't work correctly.  (It
> usually works well enough for the WebKit demo to be able to create
> a primitive web browser, but it doesn't really process all of the
> classes that're introduced by loading the new framework.  (Which
> new classes get "processed" - introduced to CLOS, basically - and
> which don't is entirely arbitrary; it may depend on the order
> in which elements in an ObjC hash table are traversed, or something
> equally unpredictable.)
>
> So, SEND tries to generate code which tests X for
> DOMCSSStyleDeclaration-ness, and finds that it has no knowledge of
> the class DOMCSSStyleDeclaration.
>
> You can probably get the WebKit example to force all classes to be
> processed by calling RESET-OBJC-CLASS-COUNT just before the call to
> MAP-OBJC-CLASSES in the function CHECK-FOR-WEBKIT in
> "ccl:examples;webkit.lisp".  You may run into other problems,
> and it's unfortunately the case that trying to load an add-on
> framework on top of Cocoa basically doesn't work reliably in 1.0;
> if it seems to, that's largely an accident.
>

  I think you might have been a bit too harsh on the functionality of  
loading additional cocoa frameworks as I've been running for over a  
month with at least 6 frameworks loaded (with several fixes you  
suggested) and they're working as expected... other than this issue  
(and a thread problem with QTKit which is probably me not  
initializing it properly),

Thanks,
Phil