Support assignment to properties of object arrays

UserCurt commented

2026-07-21 00:02:41 +00:00

(Migrated from codeberg.org)

Accessing an object array property produces a comma-separated list. MATLAB can assign one value to each object simultaneously:

[objects.Value] = deal(10, 20);

MPath currently cannot perform the equivalent assignment:

mpath.set(objects, "/Value", {10; 20}, UniformValues=false)

Resolving /Value against an object array produces terminal comma-separated-list targets, which set rejects as unsupported.

This issue proposes adding support for assignment to properties of object arrays.

It should follow the grouping and value-mapping rules in #35.
It should plan mutations described in #41 so validation is performed before any assignment occurs.

Dynamic properties

Dynamic properties have a known limitation where accessing arrays of dynamic property objects behaves differently from scalar dynamic properties. Working around this limitation is outside the scope of this issue.

addprop(objects, "DynamicValue");

objects(1).DynamicValue = 10;  % Supported
objects(2).DynamicValue = 20;  % Supported

[objects.DynamicValue]         % Errors
[objects.DynamicValue] = deal(10, 20); % Errors

Accessing an object array property produces a comma-separated list. MATLAB can assign one value to each object simultaneously: ```matlab [objects.Value] = deal(10, 20); ``` MPath currently cannot perform the equivalent assignment: ```matlab mpath.set(objects, "/Value", {10; 20}, UniformValues=false) ``` Resolving `/Value` against an object array produces terminal comma-separated-list targets, which `set` rejects as unsupported. This issue proposes adding support for assignment to properties of object arrays. - It should follow the grouping and value-mapping rules in #35. - It should plan mutations described in #41 so validation is performed before any assignment occurs. ### Dynamic properties Dynamic properties have a known limitation where accessing arrays of dynamic property objects behaves differently from scalar dynamic properties. Working around this limitation is outside the scope of this issue. ```matlab addprop(objects, "DynamicValue"); objects(1).DynamicValue = 10; % Supported objects(2).DynamicValue = 20; % Supported [objects.DynamicValue] % Errors [objects.DynamicValue] = deal(10, 20); % Errors ```

UserCurt referenced this issue

2026-07-26 14:51:06 +00:00

Support mutation through non-terminal comma-separated-list outputs #45

UserCurt commented

2026-07-26 15:11:42 +00:00

Owner

Mutation through non-terminal CSL selector outputs is now tracked separately in #45. This issue #42 remains focused on terminal CSL assignment.

UserCurt referenced this issue

2026-07-26 15:20:48 +00:00

Plan and validate mutations before applying them #41

UserCurt commented

2026-07-26 16:07:23 +00:00

Owner

There are a couple points are worth noting that complicate this issue.

First, terminal CSL assignments may not follow the order of the supplied pointers. Currently, MPath Performs set (and remove) in the order in which they appear using linear index ordering. However, MATLAB may requires all outputs to be assigned together and in output order. For example, these pointer arrays select the same outputs:

["/A/B<1>"; "/A/B<2>"; "/A/B<3>"]
["/A/B<2>"; "/A/B<3>"; "/A/B<1>"]

An unrelated target could also appear between members of the same output group:

["/A/B<1>"; "/A/B<2>"; "/X/Y"; "/A/B<3>"]

MPath would need to reorder the targets and assign their values in the order of <1>, <2>, <3> order regardless of the order in which the user specified them, and defer intermediate values until after the final one.

Second, all terminal CSL selectors will have to be present. If listLength reports three outputs, then:

["/A/B<1>"; "/A/B<2>"; "/A/B<3>"] contains the complete output group and would be a valid assignment.
["/A/B<1>"; "/A/B<3>"] and "/A/B<1>" contain only part of the group and would have to be be rejected.

To work around this, MPath could retrieve the omitted outputs and assign their existing values back to them, though that risks unintended side effects.

There are a couple points are worth noting that complicate this issue. First, terminal CSL assignments may not follow the order of the supplied pointers. Currently, MPath Performs `set` (and `remove`) in the order in which they appear using linear index ordering. However, MATLAB may requires all outputs to be assigned together and in output order. For example, these pointer arrays select the same outputs: - `["/A/B<1>"; "/A/B<2>"; "/A/B<3>"]` - `["/A/B<2>"; "/A/B<3>"; "/A/B<1>"]` An unrelated target could also appear between members of the same output group: - `["/A/B<1>"; "/A/B<2>"; "/X/Y"; "/A/B<3>"]` MPath would need to reorder the targets and assign their values in the order of `<1>`, `<2>`, `<3>` order regardless of the order in which the user specified them, and defer intermediate values until after the final one. Second, all terminal CSL selectors will have to be present. If `listLength` reports three outputs, then: - `["/A/B<1>"; "/A/B<2>"; "/A/B<3>"]` contains the complete output group and would be a valid assignment. - `["/A/B<1>"; "/A/B<3>"]` and `"/A/B<1>"` contain only part of the group and would have to be be rejected. To work around this, MPath could retrieve the omitted outputs and assign their existing values back to them, though that risks unintended side effects.

UserCurt referenced this issue

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

Define behavior for overlapping mutation targets #46

UserCurt referenced this issue from a commit

2026-07-27 00:26:44 +00:00

Support terminal comma-separated-list assignment for issue #42

UserCurt commented

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

Owner

Completed by commit 1fc1091. It schedules each UniformPaths group, validates all of them, and then performs the assignments. The scheduler requires all selectors <1> through <N> to be present and occur equal in number for the same prefix, with each one being a round of assignments.

Assignment order is largely the same with linear indexing order, but with terminal selector rounds assigned as a group at the position of its earliest member, even if some members appear later or out of order.

Assignment of partial/uneven selector groups is intentionally not supported. That would require ignoring some assignments the user provided or introducing assignments the user omitted, either of which is not ideal.

Mutation through non-terminal comma-separated-list outputs remains tracked by #45.

Completed by commit `1fc1091`. It schedules each `UniformPaths` group, validates all of them, and then performs the assignments. The scheduler requires all selectors `<1>` through `<N>` to be present and occur equal in number for the same prefix, with each one being a round of assignments. Assignment order is largely the same with linear indexing order, but with terminal selector rounds assigned as a group at the position of its earliest member, even if some members appear later or out of order. Assignment of partial/uneven selector groups is intentionally not supported. That would require ignoring some assignments the user provided or introducing assignments the user omitted, either of which is not ideal. Mutation through non-terminal comma-separated-list outputs remains tracked by #45.

UserCurt closed this issue

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

UserCurt referenced this issue

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

Define behavior for overlapping mutation targets #46

UserCurt referenced this issue

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

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

Rows
Columns

Support assignment to properties of object arrays #42

Dynamic properties