[Openmcl-devel] when is :<BOOL> == T?

[alex crain]

I'm thinking that if :<BOOL> = { T, nil} then it should always be so  
and #$YES and $#NO should be banned from the kingdom.

Current, OBJC-MESSAGE-SEND and friends do not translate #<BOOL>, but  
SEND and %SEND do.

? (defvar w (make-instance 'ns:ns-window))
#<NS-WINDOW <NSWindow: 0x3ac750> (#x3AC750)>
? (send w 'can-hide)
T
? (ccl::objc-message-send w "canHide")
#<A Mac Pointer #x1>
?

I'm not sure that I see that value of translating :<BOOL> into a lisp  
type. All the other objects in the ObjC interface are ObjC
types so it's not intuitive (to me, anyway).

If we must translate, then SLOT-VALUE, WITH-SLOTS, etc should all  
work or we end up with code that looks like this:
? (defclass C (ns:ns-object)
     ((flag :foreign-type :<BOOL>))
     (:metaclass ns:+ns-object))
? (define-objc-method ((:<BOOL> :set-flag (:<BOOL> v)) C)
   (let ((old-v (slot-value self 'flag)))
     (if v
         (setf (slot-value self 'flag) #$YES)
       (setf (slot-value self 'flag) #$NO))
     old-v))

The confusion compounds when OLD-V=0 but the method returns NIL.

You could make the case that OBJC-SEND-MESSAGE is a low level  
primitive and thus should not do translation whereas
SEND and %SEND are high level and should .... but to be honest that  
looks a lot like early C++ to me and I wasn't a fan
of that either.

It would make sense that it would be legal to send #$YES in place of  
T unless we get rid of #$YES all together.
We cold maybe modify the #$ dispatch macro so that #$YES and #$NO are  
mapped to T and nil respectively,
which would make everything uniform (at least at the symbolic level).

:alex

On Aug 5, 2005, at 6:03 PM, Gary Byers wrote:

>
>
> On Fri, 5 Aug 2005, Randall Beer wrote:
>
>
>> As far as I recall, :<BOOL>s always expect T/NIL, unless this has  
>> changed in the new SEND stuff that Gary has been doing.  I *think*  
>> that any untyped argument in a DEFINE-OBJC-METHOD defaults to :ID,  
>> which is probably not what you want.
>>
>> Randy
>>
>>
>
> The only recent related change that I'm aware of is that there's a
> real :<BOOL> foreign type in the pre-0.14.4 lisp; the interface
> translator treats :<BOOL> as being a primitive, built-in type, and the
> bridge gets method type signatures from the interface database instead
> of by querying the ObjC runtime.  (The way that the runtime encodes
> types, it wasn't possible to reliably distinguish between :<BOOL> and
> :signed-char, but it worked fairly well to assume that :signed-char
> meant :<BOOL> except in certain known/declared exceptional cases.)
>
> One case in which :<BOOL> and BOOLEAN aren't automatically mapped
> back and forth is SLOT-VALUE; the value of a slot of foreign-type
> :<BOOL> is #$YES or #NO, not t/nil.  This probably doesn't come up
> that often (there's at least one case of it in the demo IDE), but
> it might be simpler if everything in the bridge consistently mapped
> between :<BOOL> and BOOLEAN without this special case.
>