A dynamically built dispatch table also offers the ability to add handling for new cases without changing the existing ones. And it has the benefits that it is simpler to do, and doesn't push you to spread your logic across multiple files.

Okay, cool... but I'm not quite seeing how you would set that up. So let's say you have a config file that lists all the allowed cases. Wouldn't you also need to add additional code to handle additional cases, and wouldn't that imply using "multiple files"?

You are overcomplicating. See Re: replace conditionals with polymorphism for the format of a basic dispatch table. And then when I say "dynamically built" think about having a bunch of code that builds the hash that drives things. Just because it is dynamically built doesn't mean that you have to have offloaded stuff into a configuration file.

For a realistically complex example of what you can do with a dynamically built dispatch table consider Why I like functional programming. Then think about what it would take to rewrite that example in an OO fashion.

Tilly, that is one beautiful piece of code, but here's the irony - you could have made it even more general purpose by using OOP. Not, of course, by getting rid of the dispatch table (heaven forbid!), but rather by turning the configuration data into the data portion of an object and the definitions of dispatch routines into methods.

As a result, you would have a framework for multi-syntax parser that could process any mini-language that had those four tokens (open tag, close tag, open constant tag, escape code). Viewed as a whole, your code is a great example of the Type B OOP (multiple related type dependent functions). Furthermore, the idea of using a dispatch table to handle tokens is arguably a form of logical programming. The dispatch table defines a set of "rules". The rules play themselves out until they have nothing left to say.

Which all goes to the essential point of your post on why you like programming with functions. That point was the quote from Tom Christiansen to the effect that one who isn't comfortable with all the paradigms: imperative, functional, objective and logical is like a chef that knows how to boil, but not bake.

And bringing things back to video studied by the original poster, your code, OOPified or not, highlights one of the essential problems with that video (and much of OOP education) - the failure to teach which of the many kinds of relationships between data and function, function and function should be encapsulated in an object. Often the obvious ones (choosing which function to process a token) are not the important ones (defining the collection of functions for a mini-language). The fact that you need different functions for different tokens isn't like to change over time. But the definition of the function for each token easily could and probably needs to change in a coordinated manner with other rules for processing tokens.

Thanks for a good read,

Best, beth