Limited support for child discovery for custom dot-indexing classes

UserCurt commented

2026-07-02 23:30:53 +00:00

(Migrated from codeberg.org)

Classes can override properties, which can affect MPath child-discovery behavior. For example, the string class overrides the properties to have completely different semantics, not for listing properties (child discovery).

Relatedly, some classes can support dot access for names that are not discoverable through properties. This can happen when overriding matlab.mixin.indexing.RedefinesDot because it does not require exposing valid children names through properties. MPath could also use metaclass(target).PropertyList as a child discovery mechanism, but only for class-defined properties (after filtering those that are publicly accessible and visible). It will not work with dynamic properties, an dit will not reflect valid dot operations when overloaded via matlab.mixin.indexing.RedefinesDot.

MPath currently relies on child-name discovery for data-derived dot matching (e.g., in DotGlob) and future discovery-based features such as filtering (#33). Classes with non-discoverable children would have limited support in MPath. This is a known limitation without a known solution.

This is not an issue with DotExact or DotSet because matching is user-supplied rather than data-derived. The system does not need to validate paths by checking if children exist directly. Instead, the atomic chunk planner guards listLength(...) with a try-catch; if an exception is caught, it is assumed that the operation chain is not valid. This was necessary because MATLAB does not provide a standardized way via matlab.mixin.indexing.RedefinesDot to query whether a chain of indexing operations is valid for the given class instance without just trying it.

This issue is left for ideas on how to address this issue.

Classes can override `properties`, which can affect MPath child-discovery behavior. For example, the `string` class overrides the `properties` to have completely different semantics, not for listing properties (child discovery). Relatedly, some classes can support dot access for names that are not discoverable through `properties`. This can happen when overriding `matlab.mixin.indexing.RedefinesDot` because it does not require exposing valid children names through `properties`. MPath could also use `metaclass(target).PropertyList` as a child discovery mechanism, but only for class-defined properties (after filtering those that are publicly accessible and visible). It will not work with dynamic properties, an dit will not reflect valid dot operations when overloaded via `matlab.mixin.indexing.RedefinesDot`. MPath currently relies on child-name discovery for data-derived dot matching (e.g., in `DotGlob`) and future discovery-based features such as filtering (#33). Classes with non-discoverable children would have limited support in MPath. This is a known limitation without a known solution. This is not an issue with `DotExact` or `DotSet` because matching is user-supplied rather than data-derived. The system does not need to validate paths by checking if children exist directly. Instead, the atomic chunk planner guards `listLength(...)` with a try-catch; if an exception is caught, it is assumed that the operation chain is not valid. This was necessary because MATLAB does not provide a standardized way via `matlab.mixin.indexing.RedefinesDot` to query whether a chain of indexing operations is valid for the given class instance without just trying it. This issue is left for ideas on how to address this issue.

UserCurt added this to the Someday milestone

2026-07-31 12:05:43 +00:00

UserCurt added the

enhancement/feature

label

2026-07-31 12:05:46 +00:00

UserCurt commented

2026-07-31 12:20:29 +00:00

Owner

To address the lack of discoverability of children, MPath could have it's own mixin requiring a method that custom classes can implement or look for a a special method with a particular name like mpathMemberNames, which would return the list of children. This would be similar behaving to:

Class: properties or metaclass(obj).PropertyList
Struct: fieldnames
Table: T.Properties.VariableNames

Note that the proposed method should only work for children members that can be accessed through dot indexing, which is different from the children-like way the types below work:

Dictionaries: keys
Maps: keys
Categorical arrays: categories

Worth noting that it is unclear if MPath should support namespaces: namespaceClasses, namespaceFunctions, innerNamespaces or matlab.metadata.Namespace.fromName(...)

To address the lack of discoverability of children, MPath could have it's own mixin requiring a method that custom classes can implement or look for a a special method with a particular name like `mpathMemberNames`, which would return the list of children. This would be similar behaving to: - Class: `properties` or `metaclass(obj).PropertyList` - Struct: `fieldnames` - Table: `T.Properties.VariableNames` Note that the proposed method should only work for children members that can be accessed through dot indexing, which is different from the children-like way the types below work: - Dictionaries: `keys` - Maps: `keys` - Categorical arrays: `categories` Worth noting that it is unclear if MPath should support namespaces: `namespaceClasses`, `namespaceFunctions`, `innerNamespaces` or `matlab.metadata.Namespace.fromName(...)`

UserCurt referenced this issue from a commit

2026-07-31 13:21:49 +00:00

Test zero-arity methods and add limitations doc for #34

UserCurt commented

2026-07-31 13:30:27 +00:00

Owner

Commit 6803cb2 documents this known limitation in LIMITATIONS.md.

Although keys, for example, may not be discoverable, it can be still invoked by MPath when user-specified because MATLAB invokes zero-arity(ish) class instance methods when using data.(indexOps) dot indexing.

Commit `6803cb2` documents this known limitation in `LIMITATIONS.md`. Although `keys`, for example, may not be discoverable, it can be still invoked by MPath when user-specified because MATLAB invokes zero-arity(ish) class instance methods when using `data.(indexOps)` dot indexing.

Rows
Columns

Limited support for child discovery for custom dot-indexing classes #34