Hacker News Reader

Comment by viraptor | Hacker News Reader

I wouldn't say it's cringe. A factory is a factory. Calling it that in the code may not be the best idea, but having the shared vocabulary is nice. Basically, patterns work well when they're descriptive rather than prescriptive.

There are two cases that are unique though: state machines and visitors are so much things on their own, that you'll use those names almost every time you run into the pattern.

View on HN

> A factory is a factory.

Yes, but what about factory factories? https://factoryfactoryfactory.net

The visitor pattern is my go to example for patterns, that you don't really need, when you have a language that has first class functions, which implies among other things, that you can pass functions as arguments, like you can pass anything else.

The magical "visitor" pattern becomes nothing more than simple callback passing or passing a function, which is one of the most natural things to do in a modern programming language.

State machines at least are useful as a conceptual thing, to find a way to think about how one solves a problem, no matter how they are ultimately implemented in the end.

I've always seen the visitor pattern as a poor-mans pattern matching. How do you solve the same thing with callbacks?

Instead of defining a Visitor interface and then making objects to implement the interface and then passing those objects to whatever traverses a graph or iterates through something, you pass the function, that will be called, by whatever traverses a graph or iterates through something.

Kind of like how sum types and matching are implemented in library code? Example from D here:

    Fahrenheit toFahrenheit(Temperature t)
    {
        return Fahrenheit(
            t.match!(
                (Fahrenheit f) => f.degrees,
                (Celsius c) => c.degrees * 9.0/5 + 32,
                (Kelvin k) => k.degrees * 9.0/5 - 459.4
            )
        );
    }

Reply on news.ycombinator.com