"display" method for string

[gllmflndn]

The display of a string object sometimes returns the internal structure or errors in the context of string arrays:

>> string ("a")
ans =
"a"
>> {string("a")}
            ans =
            {
              [1,1] =

                string object with properties:

                         strs: [1x1 cell]
                    tfMissing: 0

            }

>> {[string ("a"), string ("b")]}
            ans =
            {
              [1,1] =

                string object with properties:

                         strs: [1x4 cell]
                    tfMissing: error: octave_base_value::bool_value(): wrong typeargument 'bool matrix'

[apjanke]

I don't think there's much I can do here, due to how Octave's OOP works. What you're looking at there is the display of Octave's cell type (what you get when you stick anything inside a {...}). Octave (and until recently, Matlab) doesn't provide a way for user-defined classes to customize their display format for when they are displayed as part of a compound type like a cell or struct. That output is Octave doing a generic object display; it's not calling the overridden disp or display methods defined by string. To affect this display, I think I would have to override or monkeypatch the core Octave cell type, and I don't think that's appropriate for a library like Tablicious.

This tfMissing: error: octave_base_value::bool_value(): wrong typeargument 'bool matrix' might be something Tablicious could handle, but maybe not; that looks like it might be an issue in Octave's generic class display code. I can report it along to them if that's the case; I'll do some testing when I have a chance.

[apjanke]

(BTW, unless you're mixing string arrays with other types of arrays, or you need arrays-of-mixed-size-arrays-of-strings or similar structures, you don't need to put string values inside cell arrays like you do with char vectors and cellstrs. The string class is itself an array type that provides the functionality of cellstrs in an alternate format.)

[gllmflndn]

The issue indeed seems to be on the Octave side. I was thinking otherwise because I have some non-classdef classes (with overloaded disp and display) that behave better:

>> {obj}
ans =
{
  [1,1] =
    <class classname>
}

I'll try and check whether this is indeed classdef-specific. Perhaps this report can be closed here.

[apjanke]

Oh huh; I didn't even know that non-classdef classes behaved differently for this. FWIW, I think their behavior that you're showing in your last comment here seems like the correct behavior for classdef classes too - less likely to blow up into a huge string displaying internal data structures that are supposed to be hidden/encapsulated, and better matches Matlab's behavior.

Those strs and tfMissing fields in the string class are intended for internal use only. They're going to be private eventually; I just left them exposed with public access for the time being to make debugging easier. I wonder what happens with the display if I make them (Access = private). I'll give that a try when I find some time.

[rajeck1234]

i want to contribute in this issue

[apjanke]

Moving the milestone for this to The Future, because I don't think there's much I can do here due to core Octave behavior, and this isn't an urgent issue that is breaking "real" data-manipulation behavior; it's a cosmetic/UI thing.