Keep the string class when a Parameter Value is retyped - #22
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
Simulink.ParameterValue typed as a string literal came back as a char: enter"abc", the cell shows'abc'.ParameterNode.setPropertyhad arms fordouble,logicalandstring-arraybut 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.
serializePropertyXmlhad no string arms either, so['abc']went down the numeric-array branch asClass="double" Dimension="1*1">abc(reparses asNaN) 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 — anElement Class="string"wrapping asaveobjcell of charElements, withDimensionomitted for 1x1. The spelling comes from the MATLAB-authored binary corpus undertest/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 chardataNodeXml.test.ts— both string shapes, escaping, indentation, and a numeric controlbinaryWriteBackGate.test.ts— binary edit → rebuild → reopenparity/fidelity/parameter.fidelity.test.ts— a round trip parametrized over both formatsLeft deliberately alone
_serializeCellElementXmlhas the identical gap one level down, but its MATLAB spelling is not pinned by any corpus example and wants a probe first.test/parity/matlab/DESIGN.md, now pinned by a control test.