[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Auto-boxing Java numerical values (cs 15820:00172e5c2302)
From: |
Philip Nienhuis |
Subject: |
Auto-boxing Java numerical values (cs 15820:00172e5c2302) |
Date: |
Thu, 20 Dec 2012 13:38:18 -0800 (PST) |
Rik,
I saw you've extended 'autoboxing' of Java doubles into Octave doubles to
Java short/long/float etc.
Isn't there a risk that this will definitely break code unavoidably
depending on the old behavior?
Example:
In the io package there's code invoking LibreOffice (behind the scenes)
through a UNO-Java bridge. Somewhere in that code LibreOffice (i.e., a UNO
Java method) expects a Java short value or object. If Octave casts that
java.lang.Short object into a double, how can that short value be conveyed
to Java? AFAICS there's no way to typecast Octave values into Java class
types. Or can we now do:
<SomeOctaveDouble>.shortValue()
? (i.e., applying Java methods to amenable Octave classes)
AFAICS Matlab simply doesn't do any, or very limited, 'autoboxing'.
Or did I misinterpret this changeset?
Philip
--
View this message in context:
http://octave.1599824.n4.nabble.com/Auto-boxing-Java-numerical-values-cs-15820-00172e5c2302-tp4648216.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Auto-boxing Java numerical values (cs 15820:00172e5c2302),
Philip Nienhuis <=