Text Oriented Programing

The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. — Alan J. Perlis

Reading Douglas Crockford’s How JavaScript Works reinforced my existing bias of “text over pointers” when it comes to data. I’m prejudiced against the conventional jargon term string for text since it’s a missuse of the word used to describe a path of lables giving a route through a state machine, which at its lowest level is text.

We do not know why we call this type string. Why do we not call it text instead? No wun knows… The equality of strings is a very powerful feature. It eliminates the need for a symbol type because similar strings are considered to be the same object. This is not true in lesser languages like Java. — Crockford

I tend to rely heavily on JSON.stringify to sidestep the common problem of checking equality of compound data. I thought it a hack to work around the problem that

["a", "b", "c"] === ["a", "b", "c"];

is false since pointer-oriented languages compare the memory addresses and not the contents of the object, whereas

JSON.stringify(["a", "b" , "c"]) === JSON.stringify(["a", "b" , "c"]);

works as expected.

I personally prefer stringify to decode and parse to encode, but Crockford wrote:

JavaScript supports JSON with two functions in the JSON object. The functions are called parse and stringify and that is entirely my fault. I chose parse following the bad example of the Date function, which we have already seen is deeply flawed. I chose stringify because toString did not seem right. I should have called the functions decode and encode.

Textual Keys

Javascript’s traditional Object as in name-value pairs enclosed in curly braces requires that the name be text.

Some programers see that as limiting, leading to the inclusion of WeakMap and Map, but I’ve never found a reason to use these.

Values in an object can be accessed by their keys using either dot, as in objectname.key, or square brackets as in objectname[key] or objectname[“key”] notation.

Something that wasn’t initially obvious to me is that the square bracket notation is more flexible in that the key can be a variable. A handy usecase of this is a “dispatcher object”.

Dispatchers

I’ve tended to use switch statements, which Crockford dissaproves of:

I do not recommend use of switch, an unholy hybrid of C. A. R. Hoare’s case statement and FORTRAN’s computed goto statement. There is nothing that can be written with the switch statement that can not be written (usually more compactly) with the if statement. The switch statement offers an implicit switch variable, but suffers from a fallthru hazard that can lead to errors and bad practices. And there is the stylistic problem: Should a case be aligned with the switch or should it be indented? There does not seem to be a correct answer.

An object can be used as an alternative to the switch statement. Fill an object with functions that implement the behavior for each case. The value matching the case variable is the key.

Textual Values

localStorage requires not only that the key, but also that the value be text, which thanks to JSON.parse is no problem.