Skip to content

Keep the string class when a Parameter Value is retyped - #22

Merged
ww-mw merged 1 commit into
mainfrom
deep-work/string-parameter-value
Sep 10, 2026
Merged

Keep the string class when a Parameter Value is retyped#22
ww-mw merged 1 commit into
mainfrom
deep-work/string-parameter-value

Conversation

@ww-mw

@ww-mw ww-mw commented Sep 10, 2026

Copy link
Copy Markdown
Member

A Simulink.Parameter Value typed as a string literal came back as a char: enter "abc", the cell shows 'abc'.

ParameterNode.setProperty had arms for double, logical and string-array but none for a plain string, so the value fell to the catch-all that stores the parser's bare JS string — and a bare JS string is how this model spells a CHAR. A 1x1 string is ['abc'].

The read path already stored ['abc'] for the same value, so the two paths disagreed about one value. That is worse than a display glitch: the table seeds its in-place editor with the displayed text, so committing a string Value's own cell unchanged silently retyped string → char and dirtied the file.

Behind that sat a second gap on the binary save path. serializePropertyXml had no string arms either, so ['abc'] went down the numeric-array branch as Class="double" Dimension="1*1">abc (reparses as NaN) and an _array_type: 'String' wrapper hit the char fallback as [object Object]. Fixing only the model would have routed every string Value straight into it, so both are fixed here: strings now write MATLAB's envelope — an Element Class="string" wrapping a saveobj cell of char Elements, with Dimension omitted for 1x1. The spelling comes from the MATLAB-authored binary corpus under test/parity/artifacts, not from a guess. MatlabVariableNode's own string writer now delegates to that shared envelope so the format has one owner.

Tests

10 new tests, all of which fail on the pre-fix tree:

  • parameterNode.test.ts — display, the cross-path invariant, commit-unchanged, embedded " escaping, and a control that a char stays a char
  • dataNodeXml.test.ts — both string shapes, escaping, indentation, and a numeric control
  • binaryWriteBackGate.test.ts — binary edit → rebuild → reopen
  • parity/fidelity/parameter.fidelity.test.ts — a round trip parametrized over both formats

Left deliberately alone

  • _serializeCellElementXml has the identical gap one level down, but its MATLAB spelling is not pinned by any corpus example and wants a probe first.
  • A char literal still stays a char where MATLAB coerces to string — the divergence already recorded in test/parity/matlab/DESIGN.md, now pinned by a control test.

A Simulink.Parameter Value typed as a string literal came back as a char:
enter "abc", the cell shows 'abc'. ParameterNode.setProperty had arms for
double, logical and string-array but none for a plain string, so the value
fell to the catch-all that stores the parser's bare JS string -- and a bare
JS string is how this model spells a CHAR. A 1x1 string is ['abc'].

The read path already stored ['abc'] for the same value, so the two paths
disagreed about one value. That is worse than a display glitch: the table
seeds its in-place editor with the displayed text, so committing a string
Value's own cell unchanged silently retyped string -> char and dirtied the
file.

Behind that sat a second gap on the binary save path. serializePropertyXml
had no string arms either, so ['abc'] went down the numeric-array branch as
Class="double" Dimension="1*1">abc (reparses as NaN) and an _array_type
String wrapper hit the char fallback as [object Object]. Fixing only the
model would have routed every string Value straight into it, so both are
fixed here: strings now write MATLAB's envelope, an Element Class="string"
wrapping a saveobj cell of char Elements, with Dimension omitted for 1x1.
The spelling comes from the MATLAB-authored binary corpus under
test/parity/artifacts, not from a guess. MatlabVariableNode's own string
writer now delegates to that shared envelope so the format has one owner.

Left deliberately alone: _serializeCellElementXml has the identical gap one
level down, but its MATLAB spelling is not pinned by any corpus example and
wants a probe first; and a char literal still stays a char where MATLAB
coerces to string, which is the divergence already recorded in
test/parity/matlab/DESIGN.md and is now pinned by a control test.
@ww-mw
ww-mw merged commit 7b94f0a into main Sep 10, 2026
1 check passed
@ww-mw
ww-mw deleted the deep-work/string-parameter-value branch September 10, 2026 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant