I don't have any superfluous lines in my code. I wanted to load a config file into my runtime, and I did. Not superfluous at all. The (extraordinarily) superfluous code is the code used to set up the object config system where none is needed.
> Not superfluous at all. The (extraordinarily) superfluous code is the code used to set up the object config system where none is needed.
You need that code to load/create rules in any case, but for you it's done from a config file which the user writes. For TFAA, the user loads his data directly into the running system. Therefore the layer you have to setup between the config file and the actual running code (parsing the config file then interpreting its values to translate them into a running ruleset) is superfluous: you can do without it.
Because you know, your "example" YAML parsing is useless in and of itself, it doesn't result in a working ruleset, you skipped the whole part where you feed that data to your code and setup the stuff that actually does work.
TFAA removes the parsing and interpretation from the chain and instead lets the user feed data directly to the running code without layers inbetween.
Because you know, your "example" YAML parsing is
useless in and of itself, it doesn't result in a
working ruleset, you skipped the whole part where you
feed that data to your code and setup the stuff
that actually does work.
Sorry, but that's not actually the case, is it? There is no "business logic" in his example. To actually use the config system he's set up, you need to evaluate Rule#charge for every rule you want to evaluate. In my example, all you could run allowed.include? or simply iterate over the allowed array.
> Data is code is data.
This is hardly a case of homoiconicity, is it?