Named argument for excluding matches #30

New issue

Open

opened 2025-10-18 01:50:05 +00:00 by UserCurt · 0 comments

UserCurt commented

2025-10-18 01:50:05 +00:00

(Migrated from codeberg.org)

The first approach is the simpler but less general of the two. The named argument would be take a string vector (or cell-char equivalent) value. Any fields within the mpath expression will exclude any fields that is a member of this set of strings. For example, in mpath.resolve(S, "/*#2/*#3", ExcludeMatches=["A", "X"]), neither *#2 nor *#3 could match the field A or the field X.

The second approach is more complex while more general. The named argument would be a dictionary mapping numbers to sets. There are two variants of this. If the numbers are indices, they would represent the occurrence index of DotGlob within the mpath expression. For example, in mpath.resolve(S, "/*#2/*#3", ExcludeMatches=dictionary(1, {"A"}, 2, {"X"}])), *#2 could not match the field A and *#3 could not match the field X. If the numbers are dimensions, they would represent the dimension in the result. For example, in mpath.resolve(S, "/*#2/*#3", ExcludeMatches=dictionary(2, {"A"}, 3, {"X"}])), *#2 could not match the field A and *#3 could not match the field X. In the later approach, it is possible a single dictionary key-value pair could restrict multiple wildcards since it would be possible for a single dimension to be associated with multiple segments.

Both approaches could be implemented as it would be unambiguous which case is being handled based on the datatype. Though of the two variants of the second approach, just one would need to be chosen.

In both approaches, a set of fields will be excluded from being matched, as if it were not a field at all. This means a value for NullField from #11 of missing or retain would not be included at all, and error would not give an error for the corresponding fields.

This feature request is intended as a stop-gap solution to introduce the feature of excluding matches from wildcards #21 prior to implementing or even deciding on syntax changes. For this proposal, `ExcludeMatches` is considered for the named argument. There are two considered approaches: The first approach is the simpler but less general of the two. The named argument would be take a string vector (or cell-char equivalent) value. Any fields within the mpath expression will exclude any fields that is a member of this set of strings. For example, in `mpath.resolve(S, "/*#2/*#3", ExcludeMatches=["A", "X"])`, neither `*#2` nor `*#3` could match the field `A` or the field `X`. The second approach is more complex while more general. The named argument would be a dictionary mapping numbers to sets. There are two variants of this. If the numbers are indices, they would represent the occurrence index of `DotGlob` within the mpath expression. For example, in `mpath.resolve(S, "/*#2/*#3", ExcludeMatches=dictionary(1, {"A"}, 2, {"X"}]))`, `*#2` could not match the field `A` and `*#3` could not match the field `X`. If the numbers are dimensions, they would represent the dimension in the result. For example, in `mpath.resolve(S, "/*#2/*#3", ExcludeMatches=dictionary(2, {"A"}, 3, {"X"}]))`, `*#2` could not match the field `A` and `*#3` could not match the field `X`. In the later approach, it is possible a single dictionary key-value pair could restrict multiple wildcards since it would be possible for a single dimension to be associated with multiple segments. Both approaches could be implemented as it would be unambiguous which case is being handled based on the datatype. Though of the two variants of the second approach, just one would need to be chosen. In both approaches, a set of fields will be excluded from being matched, as if it were not a field at all. This means a value for `NullField` from #11 of `missing` or `retain` would not be included at all, and `error` would not give an error for the corresponding fields.