# 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

is the object (a regex string).`regex`

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

, 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.`x`.`y`(`z`)

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 OOP's Jargons and Complexities]

## But Dot Notation is Easier to Read?

for example,

is more readable than `x`.a(…).b(…).c(…)`c(b(a(`

`x`)))

It is postfix notation that helps reading.

Dot notation of OOP, is 2 things. ① a postfix notation. ② 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]