[Openmcl-devel] ObjC callbacks - self and dynamic extent

[Gary Byers]

On Thu, 10 Feb 2005, alex crain wrote:

> This doesn't work...
>
> ? (defvar *x* nil)
> *X*
> ? (define-objc-method ((:void my-method sender) my-class)
>      (setq *x* sender))
> |-[MyClass myMethod:]|
> ? *x*
> #<BOGUS object @ #xCE63E>
> ?
>
> Not what I had in mind. I gather from reading the lisp kernel code that
> sender is
> dereferenced off the stack, my question is how to get it off without
> copying the object.
> I can to some hackery like this (for NSDocuments)
>
> (send (send (send self 'window-controllers) :object-at-index 0)
> 'document)
>
> Which works, but I can't believe that there isn't an easier way.
>
> Clues?
>
> :alex

You don't have to copy the (NS)Object.  You -do- have to do something
to create a persistent (heap-allocated) MACPTR that points to the
same address as the stack-allocated MACPTR that's the value of SELF.

? (define-objc-method ((:void my-method sender) my-class)
     (setq *x* (%inc-ptr sender 0))) ; one way of creating an
                                     ; EQL heap-allocated pointer

If you think "Hmm. It's kind of a PITA that callbacks try to
stack-cons parameters when they can, and you have to be aware of
this", I'd tend to agree.  (This -is- documented in the description of
DEFCALLBACK; that may or may not make it easier to remember.  I find
that getting bitten by this every now and then is a good way to stay
familiar with the issue.)

I find it harder to agree with the potential conclusion that callback
parameters should have indefinite extent by default; it's -probably-
better overall that callbacks don't do lots of incidental
heap-allocation of pointer parameters (and that you don't have to
explicitly ask for this behavior.)

(Probably.  I think that I can talk myself into and out of either
extreme-end-of-the-spectrum position.)