[armedbear-devel] SETF for JFEILDS

Alessio Stalla alessiostalla at gmail.com
Mon Nov 23 17:18:45 UTC 2009


On Mon, Nov 23, 2009 at 5:57 PM,  <logicmoo at gmail.com> wrote:
> Ok even Allegro uses T and NIL for the Booleans.. which is why
>
>> CL-USER(17):  (jclass-of (jfield "java.lang.Boolean" "TRUE"))
>> NIL
>> NIL
>
> was still correct.. I think the closer we stick with Allegro the better.
>
>
>
> for future reference (to myself) to make a boolean one does:
>
>
> CL-USER(21): (jnew  (jconstructor "java.lang.Boolean" "java.lang.String") "True")
> #<java.lang.Boolean true {44AC5E}>
> CL-USER(22): (jclass-of (jnew  (jconstructor "java.lang.Boolean" "java.lang.String") "True"))
> "java.lang.Boolean"
> "java.lang.Boolean"

If you want a boolean (primitive type) I believe you can do
(make-immediate-object T-or-NIL :boolean)
If you want Boolean.TRUE or Boolean.FALSE the cleaner way would be to
have a jfield-raw like jcall-raw, if I understand it correctly.

>
>
> If there is any action items out of all this:
>
>  Perhaps:    javaInstance()    on Nil  returns Boolean.FALSE?

This would break a lot of existing code, I'm afraid. NIL is often used
to mean null.

> Then in Symbol.java
>
>    Object javaInstance() {
>         if (this == T) return Boolean.TRUE;
>         return super.javaInstance();
>    }
>

I don't agree for consistency with NIL and for similar concerns on
existing code. However, hold on...

>
> And in LispObject itself any thoughts on?
>
>    LispObject.this.javaInstance(Class c) {
>          if (c.isInstance(this)) return this;
>       // widen and resubmit for subclasses
>          if (c==int.class) return javaInstance(Integer.class);
>          if (c==boolean.class) return javaInstance(Boolean.class);
>       // they requested a boolean.. give it to them
>          if (c==Boolean.class) return getBooleanValue();
>       .....
>          //hit the error logic
>    }

Now for javaInstance(Class) I completely agree with you: it should
mean - everywhere! - "convert this object to a Java object of the
given class, if possible".

So LispObject.javaInstance(Class c) should be like you said, and in
some subclasses (Fixnum, AbstractString come to my mind) it should be
overridden. At that point we could even generify it:

public <T> T javaInstance(Class<T> c)

So users might write, e.g., String s = myLispObject.javaInstance(String.class);

Just my €.02

Alessio

>
>
> ----- Original Message -----
> From: <dmiles at users.sourceforge.net>
> To: "Armed Bear" <armedbear-devel at common-lisp.net>
> Sent: Monday, November 23, 2009 7:42 AM
> Subject: Re: [armedbear-devel] SETF for JFEILDS
>
>
>>
>> These 3 look good
>>
>>
>> CL-USER(2): (jclass-of (jfield "java.lang.System" "out"))
>> "java.io.PrintStream"
>> "java.io.PrintStream"
>>
>> CL-USER(4): (jclass-of 1)
>> NIL
>> NIL
>>
>> CL-USER(5): (jclass-of (make-immediate-object 1))
>> "java.lang.Integer"
>> "java.lang.Integer"
>>
>>
>>
>> But is this correct?
>>
>>
>> CL-USER(17):  (jclass-of (jfield "java.lang.Boolean" "TRUE"))
>> NIL
>> NIL
>> CL-USER(18): (jclass-of (jfield "java.lang.Boolean" "FALSE"))
>> NIL
>> NIL
>>
>>
>>
>>
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>




More information about the armedbear-devel mailing list