octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #48592] function char on java objects


From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #48592] function char on java objects
Date: Thu, 19 Jul 2018 01:34:11 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Follow-up Comment #4, bug #48592 (project octave):

Here's what that doco page currently says (from
https://www.mathworks.com/help/matlab/matlab_external/handling-data-returned-from-java-methods.html):

------------------------

Convert to MATLAB Strings

To convert java.lang.String objects and arrays to MATLAB strings or character
vectors, use the MATLAB string or char function.

If the object specified in the MATLAB function is not an instance of the
java.lang.String class, then MATLAB checks its class definition for a toString
or a toChar method. 

------------------------

So, the pseudocode is, I think:


if (x instanceof java.lang.String)
  return toOctaveChar(x);
else if (x hasmethod toChar)
  return toOctaveChar(x.toChar());
else
  return toOctaveChar(x.toString());


There is no "else throw error", because _every_ Java object has a toString
method: it's defined in the root superclass java.lang.Object. Subclasses can
just provide customizations of it.

My testing agrees with this. In Matlab, `char(jobj)` succeeds on things that
clearly do not have a toChar method. In fact, it succeeds on every Java object
I could think of.


>> m = java.util.HashMap
m =
{}
>> char(m)
ans =
    '{}'
>> class(ans)
ans =
    'char'
 

That doco page also has a sidebar that says this: "If the class of the object
is not java.lang.String and it does not implement a toChar method, then the
char function displays an error message." I think they may have made a small
mistake, and meant to say "a toString or toChar method". And since every Java
object has a toString method, that sidebar is never actually relevant. Perhaps
it is left over from an older version of Matlab that did not use toString.

Octave's current behavior seems correct and Matlab-consistent to me. (Except
for the UTF-8 vs UTF-16 issue of converting Java char[] arrays, per
https://savannah.gnu.org/bugs/index.php?54170, but that's a separate issue.)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48592>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]