Consider alternative code pattern? #23

New Issue

scott · 2024-12-15T05:14:11Z

scott commented

2024-12-15 05:14:11 +00:00

Consider both Validator and Process: at current, we have a struct operating on an enum, using functions that develop in relation to the data that struct owns. My sense is that this simplifies lifetimes. It's effectively the Visitor pattern or Fold pattern, but without the abstract trait—since we don't have more than one or two visitor/folders for any given data structure.

But there's an alternative argument to be made that the nodes themselves ought to have the behaviour attached to them. So instead of a visitor pattern, any function that has to span all the branches of an enum should be defined as an impl on that type.

Maybe. Think about this.

Consider both `Validator` and `Process`: at current, we have a struct operating on an enum, using functions that develop in relation to the data that struct owns. My sense is that this simplifies lifetimes. It's effectively the [Visitor pattern](https://rust-unofficial.github.io/patterns/patterns/behavioural/visitor.html) or [Fold pattern](https://rust-unofficial.github.io/patterns/patterns/creational/fold.html), but without the abstract trait—since we don't have more than one or two visitor/folders for any given data structure. But there's an alternative argument to be made that the nodes themselves ought to have the behaviour attached to them. So instead of a visitor pattern, any function that has to span all the branches of an enum should be defined as an `impl` on that type. Maybe. Think about this.

Sign in to join this conversation.