More flexible allow/deny

[muir]

For my use case, I only want to apply the AllowList to the top level of my object. I'm thinking that rather than having an AllowList, there could be an Allower interface:

type Allower interface {
    Allow(jsonKey string) bool
    Recurse(jsonKey string) Allower
}

Recurse could return nil to indicate that there is no filtering with the key.

If this idea is acceptable to you, I might try my hand at building it sometime in the next year. While I would use it immediately if it were available, I can work around not having it for a while.

The current AllowList and DenyList could be re-implemented as things that generate an Allower.

[wI2L]

A similar question was raised in issue https://github.com/wI2L/jettison/issues/8, about the behavior of the AllowList/DenyList options.

Originally, in an earlier version, only top-levels fields were concerned by those options: https://github.com/wI2L/jettison/commit/94e9fa2473eabc41905d1959d2e549227e3a5d14#diff-e66fb2b3e2ed56aa1614ff2ff129bfd9c48111d3ec9e222e196ec18022750eb4R201

The implementation pre-computed the level of a key, and it was used to determine if it should be concerned by the option. I'm thinking that we could bring back that behavior, and update the options to specify the maximum level for keys that should be concerned, like so:

AllowList(fields []string, maxLevel int)

In terms of performance, this would require to simply check the level of a key with the maximum level of the option.

---

Regarding your proposal, I'm not sure I fully understand what you suggest. Do you imply that any types marshalled with jettison should implement the Allower interface ? If so, how the implementation would differenciate keys of the same name but at different levels ?

Otherwise, if the interface is just an abstraction as it seems you suggest it:

The current AllowList and DenyList could be re-implemented as things that generate an Allower.

then I reckon we could do without it if the goal is to simply define the maximum levels at which keys specified by the options are allowed or denied.

If we wanted something even more flexible, say:

• at level 1, allow only keys that match foo and bar
• at level 2, deny all keys that match baz
• at level 3, allow/deny everything

Then the interface could serve as an abstraction to a more complex type that would hold these information (e.g, a double map[int][]string storing the field names per priority for allowed and denied fields).