Define behavior for overlapping mutation targets

UserCurt commented

2026-07-26 21:52:44 +00:00

Owner

set and remove can receive repeated targets or targets with an ancestor/descendant relationship. For example:

["/A"; "/A"]
["/A"; "/A/B"]
["/A/B"; "/A"]

Mutation actions currently follow the linear order of the shaped targets and do not validate whether they are mutually exclusive. This issue acts as a place to define behavior when there are repeated targets or when one target is the ancestor or descendant of another.

Current behavior for set:

Repeated targets are assigned repeatedly, so the last successful assignment determines the final value.
An earlier assignment can change or remove the structure needed by a later descendant assignment, possibly causing an error.
Assignment of handle classes can also affect whether other already-validated paths can actually be assigned.

Current behavior for remove:

Repeated targets are attempted in order.
A target made absent by an earlier removal becomes a no-op.
Removing an ancestor or descendant ultimately removes the ancestor in either order.

Options include:

Preserving the current ordered behavior.
Reject overlapping targets (duplicates or ancestors/descendants).
Analyze conflicts before mutation and simulate the ordered actions. Simulating expected mutation may not be fully possible when working with handle objects.

Terminal CSL assignment #42 may require several targets to execute together as one MATLAB assignment, which can affect the order in which assignments are performed. The current issue should likely come after that is addressed to ensure ordering of assignments is better defined.

`set` and `remove` can receive repeated targets or targets with an ancestor/descendant relationship. For example: ```matlab ["/A"; "/A"] ["/A"; "/A/B"] ["/A/B"; "/A"] ``` Mutation actions currently follow the linear order of the shaped targets and do not validate whether they are mutually exclusive. This issue acts as a place to define behavior when there are repeated targets or when one target is the ancestor or descendant of another. Current behavior for `set`: - Repeated targets are assigned repeatedly, so the last successful assignment determines the final value. - An earlier assignment can change or remove the structure needed by a later descendant assignment, possibly causing an error. - Assignment of handle classes can also affect whether other already-validated paths can actually be assigned. Current behavior for `remove`: - Repeated targets are attempted in order. - A target made absent by an earlier removal becomes a no-op. - Removing an ancestor or descendant ultimately removes the ancestor in either order. Options include: - Preserving the current ordered behavior. - Reject overlapping targets (duplicates or ancestors/descendants). - Analyze conflicts before mutation and simulate the ordered actions. Simulating expected mutation may not be fully possible when working with handle objects. Terminal CSL assignment #42 may require several targets to execute together as one MATLAB assignment, which can affect the order in which assignments are performed. The current issue should likely come after that is addressed to ensure ordering of assignments is better defined.

UserCurt added this to the Release v1 milestone

2026-07-26 21:53:11 +00:00

UserCurt added the

enhancement/feature

label

2026-07-26 22:08:55 +00:00

UserCurt commented

2026-07-27 00:48:02 +00:00

Author

Owner

Issue #42 introduces one required exception to ordinary one-action-at-a-time linear indexing ordering: Each complete set of terminal comma-separated-list assignments must happen together as a group, even if some members appear later or out of order. Assignment for each complete set occurs at it earliest member. Any future ordering or overlap rules defined here should intentionally keep or replace this.

UserCurt referenced this issue

2026-07-27 08:06:30 +00:00

Share sub-paths in reverse write-backs during mutation operations #47

UserCurt referenced this issue from a commit

2026-07-29 23:14:12 +00:00

Test and add ordered mutation contract for #46

UserCurt commented

2026-07-29 23:16:17 +00:00

Author

Owner

Completed by commit 14b02f5 with additional coverage, though actual implementation has been already completed before this point.

Completed by commit `14b02f5` with additional coverage, though actual implementation has been already completed before this point.