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

I could do that, but that would be premature abstraction.

The rule of thumb that I try to live by is to not attempt to abstract something until I'm doing it for the third time. Why do I do that?

Well the first time I guarantee that I don't know how similar examples will vary and won't be able to pick a good abstraction. So attempting to abstract at that point will result in more code that is less to the point (and therefore less clear), but I'm very unlikely to find an abstraction that is useful for my next time. Which means that my abstraction has lots of real costs and no real benefits.

The second time I now have a point of comparison. I could abstract and it might work. But in my experience I still don't know enough for the cost/benefit to work out. Also at this point I am consciously fighting the second system effect.

The third time I know enough about the problem and have enough experience that I am confident that I can come up with the right abstractions. Abstractions that pay off enough in future maintenance to justify the cognitive overhead of having to learn them, and the initial effort of writing them.

Moving back to this specific example, you are perfectly right that if I had several variations of HTML format that I had to deal with, an OO layer would be a great way to go. However if I don't, adding an OO layer would add code and make it more difficult to see what is going on. It would also make other kinds of changes more difficult to make.

Let's make this concrete. In the several years since I wrote this I have never once wanted to have several similar markup languages that just varied in the syntax of the tag. (Which is what your proposed OO layer would give me.) However I have encountered other needs, such as emoticons and the need to have tags that are only allowed to open when another tag (eg a table tag) is open. Those changes would be complicated by your proposed OO interface since they cut across that interface and require changes to both sides.