Oh, that's a great way to do it. However, I recently realized that the
use-case I think this would be useful for also would require that
loose-ordering is guaranteed, which is not currently the case.
For example, assume you are passing a large protocol buffer (large
because there are many instances of a repeated, nested protocol
buffer). You want to parse the nested protocol buffers in a streaming
fashion, discarding previously parsed ones, but you need to know some
additional information in the parent protocol buffer before you can
actually do anything useful with the nested protocol buffers. If there
was a way of asserting that certain fields always come first in the
protocol buffer (not even strictly ordered, but just that they come
before repeated fields), this would make streaming a piece of cake.
However, since ordering is not guaranteed during parsing in a general
sense, there is the chance relying on ordering like this could break
in the case when a header field ends up coming after all of the nested
protocol buffers in the stream.
There's two possible ways streaming in this way could still work:
1) The ordering is deterministic as long as the fields you want to
come first existed in every version of the protocol buffer definition
and had lower field numbers than repeated fields. The downside of
hoping for this scenario is that perhaps you want to add a field later
that you would like to parse before any of the repeated nested
protocol buffers. If that happens this system will break.
2) It is guaranteed that protocol buffers are only ever serialized and
parsed once, such that intermediate parsing and serializing by older
parsers don't break the ordering. Then streaming with header-like
fields would work.
I don't know if what I said made any sense just now, but basically if
there was a way of saying in the protocol buffer definition that you
wanted certain fields (repeated, possibly) to come last always, there
would be a ton of new flexibility allowed in protocol buffer parsing
design.
If I decide that not being able to safely add new header-type fields
to these large protocol buffers before a large amount of repeated
fields is a worthwhile sacrifice, or alternatively if asserting
protocol buffers are only ever serialized and parsed once is a
worthwhile sacrifice, I may still implement this Visitor solution, but
otherwise I don't have a use for it and will probably go some other
way.
My technical writing skills are quite poor. Sorry.