Jakub Kicinski <kuba@xxxxxxxxxx> writes: > On Mon, 04 Dec 2023 16:27:24 +0000 Donald Hunter wrote: >> > Ugh. Meaning the selector is at a "previous" level of nesting? >> >> That's right. I wonder if we should use a relative syntax like "../kind" >> for the selector. Will either need to pass the known attrs to nest >> parsing, or pass a resolver instead? > > ../kind is my first thought, too. > > But on reflection I reckon it may make the codegen and Python parser > quite a bit more complex. :S That was my main concern with it too. Another thought I had was to explicitly mark attrs that get used as selector keys, but I don't think that actually buys us anything. > Passing in known selector attrs to nests sounds good. Assuming we never > have to do something like: "../other-nest/attr". > Or perhaps in that case we can support passing in nested attrs, just > not backtracking? Backtracking is the hard part, really. Yeah, that > sounds simplest, at least at the "thought exercise level" :) > > What would "resolver" look like? I was thinking a resolver would be a class with a single lookup method that internally holds attributes from the current scope and has a parent it can delegate to. It would try to resolve e.g. "kind" in current scope then, on failure, delegate to its parent. When recursing to decode a submsg, create a new resolver with the current one as its parent. If we did it this way, there'd be no need for "../kind". > BTW how do we deal with ordering. Do we require that selector attr > must be present in the message before the submsg? I think in practice > is should always be the case, but we should document that. The selector attr is de-facto present in the message before it is needed, both at the same level and for sub messages. So, yeah, I think we require this and agreed we should document it. I will do that in the next revision. >From what I have seen so far, selector attrs are at same level or at root level, but I'm not confident that will hold true for all of the raw families.
