More flexible allow/deny about jettison HOT 1 CLOSED

A similar question was raised in issue #8, about the behavior of the AllowList/DenyList options.

Originally, in an earlier version, only top-levels fields were concerned by those options: 94e9fa2#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).

from jettison.