disp architecture

[Rik]

On 10/23/2019 03:34 PM, Andrew Janke wrote:
> Here's something else to consider while we're on the subject: the disp()
> API has some limitations, especially when it comes to customizing output
> for compound data structures.
>
> Disp:
> a) Combines both conversion of a data value to a displayable string
> representation, and the outputting of that string to the console
> b) Operates on an entire array at once, instead of on individual elements
> c) Does not call disp() overrides for user-defined classes which are
> displayed inside a compound data structure like a struct or cell array.

Indeed it does have problems.  Unfortunately, resolving this is going to be
difficult because it requires close conformance to Matlab.  In effect, we
need imagination within the confines of a straitjacket.

For point a), at least Octave's disp() function can either send the string
to the console or return it to the caller for further post-processing.  As
such, a user-defined class can overload disp, use the built-in disp to get
a string representation, and then modify it before displaying it.

For point b), Matlab also operates on whole arrays so we can't get rid of
that.  Example code:

x = magic (3);
disp (x)

For point c), Matlab seems to get around this by not calling disp() at all
on elements of an aggregating data structure like a struct or cell array. 
Instead, it merely prints the name tag for the object (class and size). 
Example code

x = magic (3);
s.a = int8 (x);
s.b = single (x);
disp (s)
a: [3x3 int8]
b: [3x3 single]

We could shift to doing something like that in which case you would need to
use disp on individual elements to actually see what they contain.

If any of this seems argumentative, it's not meant to be.  I'm just trying
to lay out what the baseline is and where innovation would need to start.

--Rik