Object Oriented Programing Dot Notation Ambiguity. Data Before Dot or After Dot (2013)
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 data.
Python Example
For example, in Python you have:
string.replace(regex, replace_string)
print("this and that".replace(" ", "-")) # this-and-that
However, sometimes there's 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 data is the last parameter string, and the prefix the “re”, is the regex class object, and “sub” is a method. 〔see Python: Regex (Regular Expression)〕
import re print(re.sub(" ", "-", "this and that")) # this-and-that
JavaScript Example
This happens in JavaScript too. Here's some normal examples, where the data is the first thing:
string.replace(regex, replacement)
〔see JS: String.prototype〕
now witness this:
regex.test(string)
〔see JS: RegExp.prototype〕
Above, the data is the string, while the regex is the object (a regex string).
And, now, LOOK:
Math.sign(x)
Above, the data is the x. The “Math” is a global object, and “sign” is one of its method.
Dot Notation Ambiguity
Given x.y(z), there is no way to tell, via syntax, 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 fuck of it. Instead, everything should be a function:
namespace.function_name(data)
The data is always in the function's parameter spec, while the namespace.function_name uniquely identify its {module, namespace, purpose}. e.g.
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 Jargons and Complexities (Explained as Functional Programing)〕
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 Origin of Unix Pipe (2010)〕 - 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: JS: Function Pipe 📜
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 (2006)〕
Object Oriented Programing Dot Notation, Unix Pipe, Postfix Notation
- Object Oriented Programing Dot Notation Ambiguity. Data Before Dot or After Dot (2013)
- Node.js Dot Notation as Namespace Mechanism (2013)
- JavaScript Method Chaning vs Function Composition (2015)
- JavaScript Method Chaining is not Postfix Operator (2016)
- Ontology of Postfix Notation, Method Chaining, and Unix Pipe (2016)
- Origin of Unix Pipe (2010)
- Piping and Function Composition Equivalence (2018)