The meaning is basically different. An enumerated value doesn't always carry around additional state, neither is it expected to carry around implementation info

The meaning is basically different. An enumerated value doesn't always carry around additional state, neither is it expected to carry around implementation information. Applying polymorphism often creates an nasty inversion. If the situation is such that you need the algorithm to mutate "outside" data based on "inside" (the object) information, you end up calling a method on the object that "passes in the world." This is a particularly terrible form of coupling since it obscures the straight-line path and allows new code to break old code when it gets used out of context. The trick the article describes is more like what you would do if you were modeling this problem in SQL and decided to normalize the data into an additional table: Each enum now points to a static "program" containing various true-false properties - e.g. trucks are large, cars are not. Instead of checking the enum directly across all business logic, you can use it to look up an associated property. Subsequently, your test doesn't have to be updated to account for new types of vehicles. Algebraic data types (such as Haxe's enum) that can do a compile-time coverage check and allow parameterization are another way to attack this problem.