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.