Skip to content

Record what MATLAB does when the default enumeral is deleted - #35

Merged
ww-mw merged 1 commit into
mainfrom
enum-default-removal-probe
Sep 17, 2026
Merged

ww-mw merged 1 commit into
mainfrom
enum-default-removal-probe

Conversation

@ww-mw

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

Copy link
Copy Markdown
Member

The question

An EnumType has item1, item2, item3 and its DefaultValue is item2.
The user deletes item2. Should the displayed Value change?

Measured answer — yes, and the two flavours differ

Probed against MATLAB R2027a Prerelease 27.1.0.3393633.

Design Data (EnumTypeDefinition) Arch Data (archdata.EnumType)
removing the default enumeral allowed; live object keeps the dangling name allowed; default immediately reads the first survivor
cleared or re-pointed? neither, genuinely still stored cleared — remove the first too and the default follows
removing the LAST enumeral allowed, down to zero refused (CannotDeleteLastEnumeral)
assigning a bogus name rejected (DynamicEnum_InvalidDefaultValue) rejected, same identifier
on save invalid key dropped from the file same
on reload '' → first enumeral first enumeral

Both converge on the effective default becomes the first surviving enumeral, and
neither ever persists a DefaultValue naming an absent enumeral. Design data just
defers the tidy-up to save time.

Where we differ, and how bad it is

We keep the dangling name, so the Value column shows the deleted enumeral, no
enumeral gets the "current" icon, the dropdown displays a value outside its own
options, and we write that DefaultValue into the file.

Rather than assume the severity, the file our writer produces was handed to
MATLAB: it opens without error and silently repairs the default — both .sldd
formats, each in its own MATLAB session, because two dictionaries defining the same
enum in one session make MATLAB reuse the first definition and contaminate the
second result. So it is a display and round-trip fidelity defect, not corruption.

What is in this PR

Documentation and probes only — no behaviour change, no dist/ change. The fix is
identified in Simulink.EnumType.md and explicitly marked not implemented, so the
change to make it is a separate, reviewable commit.

Also on record: design data appends with appendEnumeral and removes by index;
arch data adds with addEnumeral and removes by name; neither add accepts a
bare name.

Two probes and the measurement they produced. The question: an enum has item1,
item2, item3 with DefaultValue 'item2'; the user deletes item2. Should the
displayed Value change?

MATLAB says yes, and the two dictionary flavours get there differently:

  Architectural Data  DefaultValue immediately reads the first surviving
                      enumeral. It is a clear-and-fall-back, not a re-point --
                      remove that one too and the default follows along. Also
                      refuses to delete the last enumeral at all.
  Design Data         the live object keeps the dangling name, but saving DROPS
                      the key, so a reload reports '' and the effective default
                      is the first survivor.

Neither ever persists a DefaultValue naming an enumeral the file lacks. Both
validate the name on assignment and neither re-validates on removal.

We keep the dangling name: the Value column shows the deleted enumeral, no
enumeral gets the "current" icon, the dropdown displays a value outside its own
options, and we write that DefaultValue into the file. Handing MATLAB the file
our writer produces settles the severity -- it opens without error and silently
repairs the default, in both .sldd formats, each checked in its own MATLAB
session because two dictionaries defining the same enum in one session make
MATLAB reuse the first definition. So this is a display and round-trip fidelity
defect rather than corruption, and it is written up in the class doc with the fix
identified and explicitly not yet applied.

The probes also correct two API guesses worth keeping on record: design data
appends with appendEnumeral and removes by INDEX, arch data adds with
addEnumeral and removes by NAME, and neither add takes a bare name.
@ww-mw
ww-mw merged commit 28a33ff into main Sep 17, 2026
1 check passed
@ww-mw
ww-mw deleted the enum-default-removal-probe branch September 17, 2026 13:55
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