On the Idiocy of Dot Notation of Object Oriented Programing Languages

, , …,

The OOP Dot Notation

the syntax of object oriented programing language is commonly like this:

object.method name(option)

where object is the meat you want to work on, and the part in round bracket option is secondary.

Python Case

For example, in Python you have:

string.split(chars)

〔☛ Python: String Methods

however, sometimes there's categorical pigeon hole problem, and the OOP language designers have a dilemma: should data be the object or class the object? This particularly happens for {string, regex, math, number} things.

For example, in Python regex, you have:

re.sub(regex, replacement, string)

where the part you really want to act on, becomes the last parameter string, and the prefix the “re”, is the regex class object. 〔☛ Python: regex Example

JavaScript Case

this happens in JavaScript too. Here's some normal examples, where the meat is the first thing:

string.split(char)

string.replace(/regex/, replacement)

〔☛ JavaScript String Methods

and now witness this:

/regex/.test(string)

〔☛ JavaScript Regex Object Methods

above, the meat is the string, while the /regex/ is the object.

and, now, LOOK:

Math.min.apply(context, list)

above, the meat is the list. The “Math” is a global object, and “min” is one of its method, and “apply” is a method inherited from a Function object.

OOP Dot Notation = Complexity Multiplied by Confoundedness

Given x.y(z), there's no way to tell, syntactically, which is the verb, which is the object. Especially so in most languages today, such as {JavaScript, Python, Ruby} , where everything is a object, including functions, and you can set it to any variable. The bottom line reached complexity multiplied by confoundedness.

solution? ban the ���� of it. Instead, everything should be a function:

namespace.function name(…)

The meat is always in the function's parameter spec, while the namespace.function name uniquely identify its {module, namespace, purpose}. ⁖ {math.sin(3), string.trim(" xyz "), regex.match("/d+", "x123"), ….}.

g+ discussion

postscript: we should note that the dot notation isn't the only possible notation for object oriented language. The functional notation as in f(x,y,z) could also work. 〔☛ What are OOP's Jargons & Complexities (OOP as Functional Programing)〕 The syntax of lisp's Common Lisp Object System is probably a good example (though i know nothing about it)

But dot notation helps reading? for example, x.h(…).g(…).f(…) is more readable than f(g(h(x)))

dot notation is a form of postfix notation. For example: x | h(…) | g(…) | f(…). (as in unix pipe. 〔☛ Unix Pipe as Functional Language〕)

Similarly, the readability advantage can be done with prefix notation, ⁖ f(…) @ g(…) @ h(…) @ x. (available in Mathematica, OCaml, Haskell, ….)

Both of these remain syntactically & semantically simple. The issue with OOP's dot notation, is the disconnection of correspondence between syntax & semantics. The problem isn't the dot notation, but OOP's convention of dot notation.

In the OOP's dot notation, given a.b.c(d), one cannot tell whether “a” is the data or “d” is the data.

For detail, see:

blog comments powered by Disqus