[armedbear-devel] Longs, Bytes, or casting in general

[Theam Yong Chew]

On 7/17/12, Theam Yong Chew <senatorzergling at gmail.com> wrote:
> On 7/17/12, Mark Evenson <evenson at 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