This message was deleted.

# general-advice

[Slackbot]

This message was deleted.

[Caleb B]

Oh wait, I forgot! The reason ASM's worked really well is because each subcategory-visit created a new instance of a SubcategoryVisitor, ensuring that methods couldn't be invoked more than once for an element on a given instance. I think my problem might just be with how this one is structured, with every subcategory method on the exact same object instead of different visitors for each. It lets you have a lot more control over how things are resolved while still allowing multiple resolution strategies.

Still, I'd love to know alternative patterns. I showed off my preliminary API to a friend and he hated it.

[Caleb B]

Wow, it's actually a very nice API when you restructure it to be object-by-object. It's just functional programming instead of a massive visitation behemoth.

I mean the fact that I can restructure it means there's nothing stopping the massive visitation behemoth from being used as a number of individual objects, so I guess the single massive class is the "less-work" way of writing it? It's just weird having them all in one place...

[Caleb B]

Also having it all as one class means you can't turn them into functional interfaces 😞

[Caleb B]

Though actually you CAN spoof it with inline companion invoke methods 👀

[Caleb B]

I think I'm starting to see how they're supposed to be put together now.

[Caleb B]

It gets a bit weirder with return values, though. You'd think you could just save whatever info you're trying to gather to a reference instead of drilling

[Caleb B]

Or I dunno put the reference in the data passed to all of the visit* methods

[Caleb B]

I do think I'm coming around to the "every type of element has a visit<it> method in the same class" thing, though. It allows you to create more flexible subvisitors, if requiring a bit more boilerplate to ensure they're only used where you want them to.