[Octave-bug-tracker] [bug #54170] java.lang.String.toCharArray result incorrect conversion to char matrix

[Andrew Janke]

Follow-up Comment #9, bug #54170 (project octave):

> But ideally the conversion UTF-8<->UTF-16 should be done automagically
whenever a java.lang.String is constructed or toCharArray is called on it.

Doing this for java.lang.String might be desirable. But doing this for
toCharArray results/`char[]` would deviate from Matlab compatibility. The
problem is that Matlab's `char` type and Java's `char[]` represent arrays of
UTF-16 code units, not strings per se. (IMHO, this is a design flaw in Matlab,
but whatcha gonna do? At least they're addressing it now with the new `string`
type.) There might also be edge cases related to Unicode normalization during
the transcoding process that would make it hard to use Java APIs that use
`char[]` as arguments.

This will run in to problems particularly with 2-D or higher `char` arrays. If
you treat them as lists of strings and transcode them, the contents of the
rows might end up being different lengths after transcoding, so they cannot be
packed back in to an N-D char array. This could be an issue for Matlab
compatibility because some Matlab code (particular older code, I think) uses
blank-padded 2-D char arrays as a way of compactly representing lists of
strings. Its string processing functions accept this as an input form.

IMHO, the abstraction levels for (Matlab) `char` and strings are different,
and if you make the `char` autoconversion too smart, you might back yourself
into a compatibility corner.

    _______________________________________________________

Reply to this item at:

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

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