On 03/07/2015 08:58, Ulrike Fischer wrote: >> - Order does not matter: just accumulate whatever is applied. > > Order will naturally still matter if one declare mutually exclusive > properties. So some clarification about which property overwrites > another would be fine anyway. Yes, I meant beyond that which is reasonably obvious from the normal keyval behaviour that a list is read/applied sequentially. I will not that point in the manual. >> - key .reset: zaps *everything* (could also be called key .delete: >> or key .clear). > > Looking at the various properties I see the following distinct > properties that one would perhaps want to reset > > .value_forbidden: > .value_required: > .groups:n > .default:xx > "known status" > "action" (all the rest without .initial:, which you can't undo) > > .default:xx, groups:n and "action" don't need imho some special > care: > > - .default:X can imho be reset with .default:n= {}. > - .groups:n can imho be reset with .groups:n = {}. Not quite for the groups case, at least at present, as your code would actually store an empty group rather than removing the data from the internal prop that manages these things. That can however be adjusted. > - the action can be reset by setting a new action. Indeed. > Missing is ".value_not_required:" and ".value_not_forbidden:". These cases where I think the reason we went with the silent reset in the first place. I wanted as far as possible to keep things simple: these names look a little awkward. I'm also not sure how such status could be flipped without some change to the 'action'. > Missing is an explicit ".unknown:", which would e.g. allow to remove > choices from a key. An accompayning ".known:" which reactivates the > key would be interesting too. (I don't know if the code allows > this). As with most keyval implementations, keys exist if they have some code defined in the right place. Activating/deactivating would therefore need the code moving to some other location: seems rather awkward for little gain. > An additional ".delete:" which clears a key completly would be good > too. I'll wait to see what others think and then look at this. -- Joseph Wright