Continuing the discussion from
Rust beginner notes & questions:
Quite a bit!
It is hard to reason about the interaction between flags. There are a lot of flags, and every time a new one is added, it’s almost guaranteed that there is some interaction that wasn’t anticipated.
This one came up in the conversation above: there are two different implementations of search in ripgrep, where one operates over buffers and one operates over a single big slice. The latter doesn’t have some features implemented, such as context handling. So one consequence of this is…
Forgive my ignorance, but is this mostly a result of some flags being basic primitives (ie bool, usize, etc)? I’m sure you’ve thought this through, but I’ll ask anyway: is there room to turn them into higher level types and attach some behavior to them that they can apply to the output? Or would that create its own abstraction spaghetti?
Is there a particular method/fn that demonstrates the issue you’re describing?
Dunno. I mean, the technique you’re describing is one I’ve employed many times over the years, so I’m not unfamiliar with it.
To me, the complexity arises in the permutation of all possible flags. There are probably competing (but perhaps not fundamental) pressures from the reduction of code duplication, abstraction soup (as you say) and performance (printing must be fast).
What I’m describing is emergent complexity in the interaction between different features. As such, there …