[Openmcl-devel] forward declare an ObjC message?

Gary Byers gb at clozure.com
Thu Feb 10 16:00:41 PST 2005



On Thu, 10 Feb 2005, Randall Beer wrote:

>
> Yes, SEND tries to optimize the call based on the name of the message.
> Using the function %SEND instead should do what you want: (%SEND
> (@CLASS A-WINDOW) 'SHOW-ME)
>
> For what it's worth, the following will also work:
>
> (LET ((MSG 'SHOW-ME))
>    (SEND (@CLASS A-WINDOW) MSG))
>
> because it forces SEND to expand into %SEND since the message is
> unknown at compile-time.  It should be fairly easy to change SEND so
> that it also expands into %SEND when given a constant message that is
> undefined at compile-time.
>
> However, you must realize that using %SEND is much more expensive that
> using SEND because all of the message signature and type processing and
> foreign function call cruft will then be done at runtime rather than
> compile-time. This may be OK for some of your messages, but you
> definitely don't want to do this for any time-critical code.
>
> The only way to forward reference messages would be to "explain" their
> types to the bridge. It should be possible to write such a utility that
> makes an entry in the type signature table fairly easily, but
> essentially it would be equivalent to giving a DEFINE-OBJC-MESSAGE
> definition with an empty body.
>
> Randy
>

I wonder if it'd be possible/easy to do something like (not sure of the
syntax):

(declare-objc-message ((:void show-me) a-window))

which would basically have the effect of describing the message signature
without saying anything about the implementation ?  (That's sort of what
happens when libraries are imported now, and it happens as a side-effect
of DEFINE-OBJC-METHOD, as well.)

(The idea is that this would provide a way to tell SEND what it needed
to know to compile calls efficiently, without forcing methods to be
implemented before calls to them can be compiled.)

Without thinking about it too hard, I -think- that that'd be fairly
easy to do.  (Famous last words.)



More information about the Openmcl-devel mailing list