[armedbear-devel] TYPE-ERROR #<java.lang.String foo {BADEAFFE}> cannot be coerced to a string.
Hi. Just stumbled across this one when I tried to use STRING-EQUAL to compare a value I received via JINTERFACE-IMPLEMENTATION. Now, it appears to be very simple to allow the expression (string (jnew "java.lang.String" "foo")) by overriding STRING() in JavaObject and checking if obj is a (java) String. What do you think? Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12751) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,14 @@ return super.typep(type); } + @Override + public LispObject STRING() + { + if (obj instanceof String) + return new SimpleString(obj.toString()); + return super.STRING(); + } + public final Object getObject() { return obj; -- CYa, ⡍⠁⠗⠊⠕
On Sat, Jun 12, 2010 at 3:40 PM, Mario Lang <mlang@delysid.org> wrote:
Hi.
Just stumbled across this one when I tried to use STRING-EQUAL to compare a value I received via JINTERFACE-IMPLEMENTATION.
Now, it appears to be very simple to allow the expression
(string (jnew "java.lang.String" "foo"))
by overriding STRING() in JavaObject and checking if obj is a (java) String.
What do you think?
I think it would be a valuable addition, but why limit it to Strings? (string java-object) could always return the result of calling toString() on the wrapped object, or "null" when it's null. Bye, Alessio
Alessio Stalla <alessiostalla@gmail.com> writes:
On Sat, Jun 12, 2010 at 3:40 PM, Mario Lang <mlang@delysid.org> wrote:
Just stumbled across this one when I tried to use STRING-EQUAL to compare a value I received via JINTERFACE-IMPLEMENTATION.
Now, it appears to be very simple to allow the expression
(string (jnew "java.lang.String" "foo"))
by overriding STRING() in JavaObject and checking if obj is a (java) String.
What do you think?
I think it would be a valuable addition, but why limit it to Strings? (string java-object) could always return the result of calling toString() on the wrapped object, or "null" when it's null.
Thats certainly an option, but I didn't want to make the initial proposal to broad. :-) toString() is a method of java.lang.Object, so JavaObject#STRING could indeed just call toString without checking for the class of obj. In fact, the more I think of it the better it sounds. If there is consensus, I can prepare an update patch if need be (its simple enough anyways). -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/> .''`. | Get my public key via finger mlang/key@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
On Mon, Jun 14, 2010 at 9:30 PM, Mario Lang <mlang@delysid.org> wrote:
Alessio Stalla <alessiostalla@gmail.com> writes:
On Sat, Jun 12, 2010 at 3:40 PM, Mario Lang <mlang@delysid.org> wrote:
Just stumbled across this one when I tried to use STRING-EQUAL to compare a value I received via JINTERFACE-IMPLEMENTATION.
Now, it appears to be very simple to allow the expression
(string (jnew "java.lang.String" "foo"))
by overriding STRING() in JavaObject and checking if obj is a (java) String.
What do you think?
I think it would be a valuable addition, but why limit it to Strings? (string java-object) could always return the result of calling toString() on the wrapped object, or "null" when it's null.
Thats certainly an option, but I didn't want to make the initial proposal to broad. :-) toString() is a method of java.lang.Object, so JavaObject#STRING could indeed just call toString without checking for the class of obj. In fact, the more I think of it the better it sounds.
If there is consensus, I can prepare an update patch if need be (its simple enough anyways).
+1 :) I just wanted to add that I checked that the CL standard allows this: "string might perform additional, implementation-defined conversions". Bye, Alessio
On Tue, Jun 15, 2010 at 8:47 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 15 June 2010 00:26, Alessio Stalla <alessiostalla@gmail.com> wrote:
If there is consensus, I can prepare an update patch if need be (its simple enough anyways). +1 :)
+1 as well.
Completely fine by me. So, it looks like we are completely in agreement :-) Bye, Erik.
Erik Huelsmann <ehuels@gmail.com> writes:
On Tue, Jun 15, 2010 at 8:47 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 15 June 2010 00:26, Alessio Stalla <alessiostalla@gmail.com> wrote:
If there is consensus, I can prepare an update patch if need be (its simple enough anyways). +1 :)
+1 as well.
Completely fine by me. So, it looks like we are completely in agreement :-)
OK, here is a new patch that implements the suggested behaviour: Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12752) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,12 @@ return super.typep(type); } + @Override + public LispObject STRING() + { + return new SimpleString(obj != null? obj.toString(): "null"); + } + public final Object getObject() { return obj; Alternatively, here is a version that still emits a type error if the wrapped object is null. I am really not sure whats better, so I offer both versions. Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12752) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,14 @@ return super.typep(type); } + @Override + public LispObject STRING() + { + if (obj != null) + return new SimpleString(obj.toString()); + return super.STRING(); + } + public final Object getObject() { return obj; Please apply what you like the most. -- Thanks, ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/> .''`. | Get my public key via finger mlang/key@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
On Tue, Jun 15, 2010 at 4:49 PM, Mario Lang <mlang@delysid.org> wrote:
Erik Huelsmann <ehuels@gmail.com> writes:
On Tue, Jun 15, 2010 at 8:47 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 15 June 2010 00:26, Alessio Stalla <alessiostalla@gmail.com> wrote:
If there is consensus, I can prepare an update patch if need be (its simple enough anyways). +1 :)
+1 as well.
Completely fine by me. So, it looks like we are completely in agreement :-)
OK, here is a new patch that implements the suggested behaviour:
Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12752) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,12 @@ return super.typep(type); }
+ @Override + public LispObject STRING() + { + return new SimpleString(obj != null? obj.toString(): "null"); + } + public final Object getObject() { return obj;
Alternatively, here is a version that still emits a type error if the wrapped object is null. I am really not sure whats better, so I offer both versions.
Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12752) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,14 @@ return super.typep(type); }
+ @Override + public LispObject STRING() + { + if (obj != null) + return new SimpleString(obj.toString()); + return super.STRING(); + } + public final Object getObject() { return obj;
Please apply what you like the most.
I applied and committed the first one, on the basis that Java does the same conversion when using the + operator. Thanks, Alessio
participants (4)
-
Alessio Stalla -
Erik Huelsmann -
Mario Lang -
Ville Voutilainen