Hi folks,
I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example,
(jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION]
Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar:
(jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}>
Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long?
Yong
On Jul 17, 2012, at 4:19 , Theam Yong Chew wrote:
Hi folks,
I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example,
(jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION]
Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar:
(jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}>
Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long?
I haven't thought about this in any detail, but my gut feeling is that in general you want to avoid automagic typecasting. Otherwise, calling constructors overloaded with, e.g., byte vs integer becomes an upredictable mess. I guess both of your use cases above could be served with something like
(defun jbyte (number) (jnew (jconstructor "java.lang.Byte" "byte") number))
plus some more magic if the value passed in is already a java.lang.Byte, or other number-like object (downcasting a Java Integer object to Byte if within range, etc.) Similar for the other primitive Java datatypes. (I don't know if we have something like that already, but it does seem useful.)
Rudi
On Jul 17, 2012, at 04:19 , Theam Yong Chew wrote:
Hi folks,
I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example,
(jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION]
Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar:
(jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}>
Unfortunately, I can't think of a way around this off the top of my head, although I may be missing something. I suppose what we would want would be some sort of algorithm that would keep trying constructors by casting the types of parameters up/down their inheritance trees until it found a match. Although it would be rather unsafe (from thinking about it briefly about casting things between signed/unsigned representation), it might be useful enough to construct something for experimentation.
Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long?
JCOERCE does this:
CL-USER> (jcoerce 23 "byte") #<java.lang.Byte 23 {3A5F299D}>
although it always wraps primitive types in the associated numeric tower class.
On 7/17/12, Mark Evenson evenson@panix.com wrote:
On Jul 17, 2012, at 04:19 , Theam Yong Chew wrote:
Hi folks,
I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example,
(jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION]
Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar:
(jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}>
Unfortunately, I can't think of a way around this off the top of my head, although I may be missing something. I suppose what we would want would be some sort of algorithm that would keep trying constructors by casting the types of parameters up/down their inheritance trees until it found a match. Although it would be rather unsafe (from thinking about it briefly about casting things between signed/unsigned representation), it might be useful enough to construct something for experimentation.
Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long?
JCOERCE does this:
CL-USER> (jcoerce 23 "byte") #<java.lang.Byte 23 {3A5F299D}>
although it always wraps primitive types in the associated numeric tower class.
Thanks Mark & Rudi, good thoughts. I have used my own specific wrappers in the class, but am looking for something lazier this time. jcoerce could be what I need for that, while writing a specific wrapper (as Rudi suggested) could be used in more "formal" settings.
Cheers & happy consing,
Yong
On 7/17/12, Theam Yong Chew senatorzergling@gmail.com wrote:
On 7/17/12, Mark Evenson evenson@panix.com wrote:
On Jul 17, 2012, at 04:19 , Theam Yong Chew wrote:
Hi folks,
I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example,
(jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION]
Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar:
(jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}>
Unfortunately, I can't think of a way around this off the top of my head, although I may be missing something. I suppose what we would want would be some sort of algorithm that would keep trying constructors by casting the types of parameters up/down their inheritance trees until it found a match. Although it would be rather unsafe (from thinking about it briefly about casting things between signed/unsigned representation), it might be useful enough to construct something for experimentation.
Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long?
JCOERCE does this:
CL-USER> (jcoerce 23 "byte") #<java.lang.Byte 23 {3A5F299D}>
although it always wraps primitive types in the associated numeric tower class.
Thanks Mark & Rudi, good thoughts. I have used my own specific wrappers in the class, but am looking for something lazier this time. jcoerce could be what I need for that, while writing a specific wrapper (as Rudi suggested) could be used in more "formal" settings.
Cheers & happy consing,
Yong
Oops, are these expected?
(jcoerce 23 "byte") ==> #<java.lang.Byte 23 {7EA742A1}>
(jcoerce 23 "int") ==> #<java.lang.Integer 23 {6E7C6928}>
All seems good, but this seems exceptional,
(jcoerce 23 "long") ; Evaluation aborted on #<TYPE-ERROR {4AAA045F}>.
(jcoerce (expt 2 128) "long") ==> ; Evaluation aborted on #<TYPE-ERROR {BCAB4A5}>.
Additionally, what about these?
(jcoerce 23 "float") ==> ; Evaluation aborted on #<TYPE-ERROR {3E478AD6}>.
(jcoerce 23 "double") ==> ; Evaluation aborted on #<TYPE-ERROR {4AC5AF5C}>.
It seems we have to use a closer matching type:
(jcoerce 23.0 "float") ==> #<java.lang.Float 23.0 {5DC7C133}>
(jcoerce 23d0 "double") ==> #<java.lang.Double 23.0 {11E63F4A}>
Is long missing support, and should float/doubles be automatically handled too? I suspect your previous comment means yes?
Cheers,
Yong
On Jul 20, 2012, at 09:03 , Theam Yong Chew wrote:
On 7/17/12, Theam Yong Chew senatorzergling@gmail.com wrote:
On 7/17/12, Mark Evenson evenson@panix.com wrote:
On Jul 17, 2012, at 04:19 , Theam Yong Chew wrote:
Hi folks,
I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example,
(jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION]
Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar:
(jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}>
Unfortunately, I can't think of a way around this off the top of my head, although I may be missing something. I suppose what we would want would be some sort of algorithm that would keep trying constructors by casting the types of parameters up/down their inheritance trees until it found a match. Although it would be rather unsafe (from thinking about it briefly about casting things between signed/unsigned representation), it might be useful enough to construct something for experimentation.
Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long?
JCOERCE does this:
CL-USER> (jcoerce 23 "byte") #<java.lang.Byte 23 {3A5F299D}>
although it always wraps primitive types in the associated numeric tower class.
Thanks Mark & Rudi, good thoughts. I have used my own specific wrappers in the class, but am looking for something lazier this time. jcoerce could be what I need for that, while writing a specific wrapper (as Rudi suggested) could be used in more "formal" settings.
Cheers & happy consing,
Yong
Oops, are these expected?
(jcoerce 23 "byte") ==> #<java.lang.Byte 23 {7EA742A1}>
(jcoerce 23 "int") ==> #<java.lang.Integer 23 {6E7C6928}>
All seems good, but this seems exceptional,
(jcoerce 23 "long") ; Evaluation aborted on #<TYPE-ERROR {4AAA045F}>.
(jcoerce (expt 2 128) "long") ==> ; Evaluation aborted on #<TYPE-ERROR {BCAB4A5}>.
Additionally, what about these?
(jcoerce 23 "float") ==> ; Evaluation aborted on #<TYPE-ERROR {3E478AD6}>.
(jcoerce 23 "double") ==> ; Evaluation aborted on #<TYPE-ERROR {4AC5AF5C}>.
It seems we have to use a closer matching type:
(jcoerce 23.0 "float") ==> #<java.lang.Float 23.0 {5DC7C133}>
(jcoerce 23d0 "double") ==> #<java.lang.Double 23.0 {11E63F4A}>
Is long missing support, and should float/doubles be automatically handled too? I suspect your previous comment means yes?
Looks like our implementation is buggy. Need to collect all the info, and file an issue.
armedbear-devel@common-lisp.net
-
Mark Evenson -
Rudi Schlatte -
Theam Yong Chew