dbj.cond shapes catalogue

dbj.cond is one very flexible thing. But here in lies its hidden complexity: the flexibility sometimes brings benefits hard to understand. And what is hard to understand one tends to avoid.

So, I have decided to catalog what I am calling “shapes” of dbj.cond.  They are not “use cases” (UC).  UC’s are showing concrete real life examples of dbj.cond usage. While Shapes are generic description of an finite number of  coding idioms, shaping dbj.cond  usage.

In this dbj.cond shapes catalogue each shape has a name, javascript pseudo code and a diagram.

dbj.cond shapes catalogue

Standard LISP COND — multiple outcome conditional statement

Lisp syntax of the COND statement is this:

Result of condition is true or false. If true it’s pair value is returned and COND stops. If none is true the value of the last pair  (T (value_4)) is returned. ‘T’ is true in LISP.

In JS syntax the equivalent is this.

dbj.cond has as a first argument the input value.  so that each “condition” from above is actually a comparison of that  input value to whatever we need to compare.  To shape it up to behave like a basic LISP cond we simply give ‘true’ as the input value.

Were conditions are any JS expressions resulting in true or false.

Basic LISP cond reversed

Since JS can be obligatory mind-bending  we will introduce an sub shape to this which does exactly the opposite. It stops the conditional multi selection if the condition met is false.

If any of the expressions representing the conditions above yields false, dbj.cond stops and returns its value sibling. Lisp COND can not do that.

Standard dbj .cond() logic flow

Each and every dbj.cond shape conforms to the above diagrammatic representation of its internal processing.

It is important to note the “comparisons”. The dbj.cond comparisons are performed by  primary and secondary comparator functions.  If secondary is set that is.

JavaScript (JS) has a function as the “first class” object.  Nothing is stopping us  to use functions in place of any argument to the dbj.cond() , some arguments or in place of all arguments that is.

Canonical Functional shape of dbj.cond

Any shape of mixing functional and non functional arguments is of course possible. As long as the underlying comparator can handle them.

Please keep in mind the underlying comparators. In the case of using any variant of this dbj.cond shape comparator must be able to compare functions.

And this is where one meets head on, so called JS minefields, like this one:

Moral of the snippet for comparator writers: It is hard to  decide how to compare two functions in an browser agnostic way and in the EcmaScript  standard version, agnostic way too.