DIN BLOGURILE MOLDOVEI
Musings
As I promised here are my thoughts:1. First of all, pattern matching lets you describe what yo eed with little or no effort. For example, consider these rules:{field}
{field, Func}
{field, {'=', field2}}
Frankly, I have a very vague idea how these could be matched using ifs only. I guess you would create a Rule class and inherit a slew of classes from it. Something like RuleField, RuleFunc, RuleOperator and so on. If you use pattern matching, however, the rules are easily parsed::%%{field}
validate_rule({FieldName}) ->
ok.
%%{field, Func}
validate_rule({FieldName, Func}) when is_function(Func) ->
ok.
%%{field, {'=', field2}}
validate_rule({FieldName, {Operator, FieldName2}}) ->
ok.
Such ease, however, may bring (and it does bring me) to my second thought:2. WTF-ish code. The thought that you can easily slice through complex constructs makes you write before you think.In my case I knew what I wanted to pass to the function, but I had no idea what I expected the function to return. Ok, I've parsed the rules, what now?As a result, the first version of the function would return a deeply nested list of lists that looked something like this:
[[Field, [Error1, Error2]], [Field2, [Error3, Error4]]]
It took me two additional refactorings to make it return a properproplist.This same "wow, look at how I handle things!" approach resulted in an ugly preprocessing of results before I return these to the user:
lists:filter(
fun(Elem) ->
case
Elem of {} -> false;
{_, []} -> false;
_ -> true
end
end,
lists:flatten(validate1(A, ValidationRules, [])))
Yup. Get rid of those unwanted elements before the user sees them. Are you scared? I am. I m saddened as well :(Here's where my train of thoughts stops...