A Functional Programing Architecture on JavaScript and Object Oriented Document Object Model

By Xah Lee. Date:

(xah rumination extempore, episode №20131208194112)

so, today i've been reworking on some of my tutorials on JavaScript/DOM scripting. For example: JS: Most Frequently Used DOM Methods

and for example, you can use document.getElementById(id) to get a element, then you can use methods such as insertBefore(), and also properties such as node.firstChild, node.nextSibling, etc to work on it.

i always believed that computer languages or most tech don't need object oriented programing. Functional programing should be sufficient. (for example, see: Object Oriented Programing (OOP) Jargons and Complexities)

So, it occured to me, how'd i do this if it is FP?

that is, DOM is a OOP system. You have objects, and each has methods. It's a big OOP. What would be a FP system of DOM be like? So, i went on to think about that, and in 20 min roughly sketched out.

so, to do the same, as if DOM is a FP architecture, it's like this.

you use a function named getElementById(document, id) to get a element. This function has 2 parameters. First is a data of a particular type, let's call it document, which represent a parsed html source code. The second arg would be the usual id string.

So, a example call would be like this: getElementById(document, "x2938"). The “document” there is a global, predefined variable. It is set when the FP DOM system finished parsing the html. (not much different as in OOP DOM)

then, how'd one call the method nextSibling if there is no method?

it's like this. call the function nextSibling(node). It'll take one argument, a data of type node.

… so, i think the above is pretty much it. A FP architectured DOM. No OOP “objects” or “methods”. It's just all functions, and data types. The different data types corresponds to different “objects” in dom. And, we have a set of functions. Each, takes parameters, and the parameter much match type, as usual.

in general, any “object” in object.methodName(args) becomes functionName(object, args). And the object is of a particularly typed data.

Class/Object Hierarchy and Namespace in FP System

In OOP, the class, object, or data, has a hierachy or grouping. That is, given a object, you know exactly which methods/functions that can work on it. And or, given a class/method/function, you know exactly which other class/method/function is grouped under it, or where it fits in a classification tree. This is due to inheritance, a fundamental idea of OOP.

In FP, similar things can correspond to namespace, library hierachy, and function signature together with type system can let us know what functions are applicable to a piece of data. This can be done by simply having a function that lists all functions that take a particular data type. So, you can have one generic function ShowTypes(f), which basically return the function's parameters and their type. And a function ListFunctionsBySignature(type) which will return a list of all functions that have type as a parameter.

alternatively, in FP, each function can have properties, and its value can be anything, including a function. For example, this is so with lisp. This actually is similar to JavaScript's object system. [see Understanding JavaScript Object System] So, this can also be used as a OO system for grouping functions.

{Reference, Object, Internal Representation} vs {Data Serialization, Read Syntax}

In thinking about this, another issue came up is what OOP community calls “data serialization”.

In computer languages, typically you have something you typed (aka “literal expression”, “serialized data”, “printed representation”, “read syntax”), and its internal representation (the “object”, and “reference” pointing to it).

In OOP languages and low-level languages (For example, C, Java, Python, Perl), typically, data or objects are opaque entities, programer refer to them by “reference”, and only some of them have a “literal expression” or “serialized representation”. The opaque thing is typically more emphasized, that programer create and work on. While the literal expression is less emphasized, and has secondary focus. Only some entities in the language has “literal expression” or serialized form.

In FP languages (For example, lisp), especially math oriented one (For example, Mathematica, MATLAB), the “literal expression” or “read syntax” is more emphasized. Almost every entity of the lang has a read syntax. Programers work with that directly. The internal representation is less emphasized, avoided as much as possible, or the concept of reference doesn't exist.

So, in converting OOP system to FP system, one question is how to deal with the “object”, which is a opaque entity that is coupled with the “reference” concept to work with them. For example, the “document” in document.getElementById(id) is one such example. I think, in general, the FP system would have “types”, that correspond to the different “object” or “reference” types, and for global OOP objects, FP system would have predefined global variables that hold a value of such OOP object as a specifically typed data.

just a quick thought. Did i miss anything that'd be problematic for a FP DOM?

Functional Chaining for the Dotted Notation Method Chaining

In OOP, you have this convenient notation for chaining:

obj.method1(arg1).method2(arg2).method3(arg3)

In functional programing, that can be done by having a post-fix notation, such as unix pipe:

method1(obj, arg1) | method2(arg2) | method3(arg3)

For detail, see: Concepts and Confusions of Prefix, Infix, Postfix and Lisp Notations

[Google Plus discussion https://plus.google.com/+XahLee/posts/4HMN6cHhA44]