Preferably, the REPL would not display "private" (underscore prefixed properties). These properties seem to be inherited from the base ndarray class. They are not set as non-enumerable properties for performance reasons.
When setting as non-enumerable in the non-"base" ndarray constructor, there was a non-negligible performance impact which subsequently affected downstream usage of ndarrays. This was documented here.
In general, return value representation should be standardized across the stdlib REPL. Possibly by implementing a custom inspect method which is invoked prior to displaying the return value in the REPL, similar to the built-in Node.js REPL.
Related Issues
Does this issue have any related issues?
No.
Questions
Any questions for reviewers?
No.
Other
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
Reproduction
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
launch the stdlib REPL
create an ndarray and do not silence output
Expected Results
What are the expected results?
The following results are expected:
<ndarray>[ <contents> ]
or something like what is generated by ndarray#toString().
Actual Results
What are the actual results?
The following are the actual results:
(see above)
Environments
What environments are affected (e.g., Node v0.4.x, Chrome, IE 11)? If Node.js, include the npm version, operating system, and any other potentially relevant platform information.
The following environments are affected:
all environments which might care about property enumerability.
Checklist
Description
Encountered the issue when creating an
ndarray
in the REPL. Currently, when displaying anndarray
as a return value, the following is shown:Preferably, the REPL would not display "private" (underscore prefixed properties). These properties seem to be inherited from the base
ndarray
class. They are not set as non-enumerable properties for performance reasons.When setting as non-enumerable in the non-"base"
ndarray
constructor, there was a non-negligible performance impact which subsequently affected downstream usage ofndarrays
. This was documented here.In general, return value representation should be standardized across the stdlib REPL. Possibly by implementing a custom
inspect
method which is invoked prior to displaying the return value in the REPL, similar to the built-in Node.js REPL.Related Issues
No.
Questions
No.
Other
Reproduction
In order to reproduce this bug, do the following:
Expected Results
The following results are expected:
or something like what is generated by
ndarray#toString()
.Actual Results
The following are the actual results:
Environments
The following environments are affected: