OOP Dot Notation, Dot Before Data or After?
In the dot notation of object oriented programing language design, there's a dilemma, a inconsistency, of whether data comes before dot, or after the dot.
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)
[see 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 meat is the last parameter string, and the prefix the “re”, is the regex class object. [see 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)
[see JavaScript String Methods]
now witness this:
regex.test(string)
[see JavaScript Regex Object Methods]
Above, the meat is the string, while the regex
is the object (a regex string).
And, now, LOOK:
Math.max.apply(context, list)
Above, the meat is the list. The “Math” is a global object, and “max” is one of its method, and “apply” is a method inherited from a Function object.
- JavaScript: Understanding Prototype and Inheritance
- JavaScript: Keyword “this”
- JavaScript: f.call f.apply f.bind
- JavaScript: Math Methods
OOP Dot Notation = Complexity Multiplied by Confoundedness
Given x.y(z)
, there is no way to tell, syntactically, which part is the data.
Especially so in most languages today, such as
{JavaScript,
Python,
Ruby}
, where everything is a object, including function and data, and you can set it to any variable.
The bottom line reached complexity multiplied by confoundedness.
solution? ban the fsck of it. Instead, everything should be a function:
namespace.function_name(data)
The meat is always in the function's parameter spec, while the namespace.function_name uniquely identify its {module, namespace, purpose}.
For example: {math.sin(3)
, string.trim(" xyz ")
, regex.match("x123", "/d+")
, ….}.
[google plus discussion https://plus.google.com/+XahLee/posts/Wbjqeqw5HCq]
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)
(meaning
className(methodName, data1, data2)
)
could also work. [see Object Oriented Programing (OOP) Jargons and Complexities]
But Dot Notation is Easier to Read?
for example, x.a(…).b(…).c(…)
is more readable than c(b(a(x)))
It is postfix notation that helps reading.
Dot notation of OOP, is 2 things. (1) a postfix notation. (2) requires a relation between 2 operands, usually, the left side is a class or object, and the right side is its method/property.
You do not need OOP dot notation to have post-fix notation.
Here is some example of postfix or prefix notation.
- Unix shell's pipe.
cat file | grep "x" | grep -v "y" > out
[see Unix Pipe as Functional Language] - Clojure.
(-> x a b c)
[see Clojure: Function Chaining] - Wolfram Language's postfix syntax:
x // a // b // c
[see Mathematica] - Wolfram Language's prefix syntax:
c @ b @ a @ x
[see Mathematica]
See also: JavaScript: Pipe Function Instead of Method Chaining
All of the above, has sequential forms that are not nested.
In the functional prefix or postfix notation, the syntax and semantics has a simple correspondence.
The issue with OOP's dot notation, is the irregular correspondence between syntax and semantics.
In the OOP's dot notation, given a.b.c(d)
, sometimes “a” is the data, sometimes “d” is the data. It is impossible to know syntactically.
[see Concepts and Confusions of Prefix, Infix, Postfix and Lisp Notations]