on the idiocy of OOP dot notation
xah's rumination extempore❕ episode №20131128221110

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.

For example, in Python you have:


however, sometimes there's categorical pigeon hole problem, and the OOP lang 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(‹pattern›, ‹replacement›, ‹string›)」

where the part you really want to act on, becomes the last parameter ‹string›, and the prefex the “re”, is the regex class object. 〔Python: regex Example http://xahlee.info/perl-python/regex.html

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


「‹string›.replace(/‹pattern›/, ‹replacement›)」

and now witness this:

「‹regex pattern›.test(‹string›)」

above, the meat is the ‹string›, while the regex pattern is the object. 〔 JavaScript Regex Tutorial http://xahlee.info/js/js_regex.html

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 the Global object.

the bottom line, is complexity multiplied by confoundedness.

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

math.f(x1, x2, x3, …)

The meat is the first thing in the function's parameter spec, while the “math.f” uniquely identify its {module, namespace, purpose}.

Complimentary essay:
What are OOP's Jargons & Complexities (OOP as Functional Programing)

#python   #javascript
Shared publiclyView activity