Update This post continues here, in the
JavaScript _super Bullshit one.
In my precedent post I have discussed about few common JavaScript errors, included the classic
new Class() call to retrieve a runtime created function, populating its prototype.
While my suggestion is both semantic and reasonable, I am pretty sure nobody on earth will ever implement that
native Function wrapper, and this is the reason I am posting again, this time hopefully with a better suggestion.
JavaScript Class Abstract Concept
It's extremely hard to understand for those with classic OOP background but
JavaScript has no Classes, just objects, where functions are first class objects but still objects!
Assumed this, we can try in any case to think about a JavaScript Class as a "
function which aim is to create instances of function itself".
What Is Wrong Right Now
What I argued about in my precedent post is that this statement is too often unconsidered:
// try with Mootools or some other library
new Class({}) instanceof Class;
// FALSE, since Class returns a function
// and not the created instanceof Class
Above misconception about what a Class is and how meaningless and redundant is the
new keyword in latter case is truly annoying me!
The reason developers want "
Classes" in JavaScript is because they think their OOP knowledge is better than what JS already offers, so why on earth they should create and use such hybrid nonsense?
A Class IS A Function
Nothing more and nothing less. The fact we would like to use that function to create and initialize instances is
just how every Functions work, or if we prefer, a developer convention and a quick way to chain a prototype into an object.
Since a Class is a Function, and whatever "
new Class()" will always be an "
instanceof Function",
Class.prototype should be exactly the Function.prototype one, so that nobody can ever say again: "
Look, I have created a Class" ... no bullshit Sherlock, you created a Function!
How To Define A "Class"
If we think about classical OOP languages, the only way to use a Class is to define it indeed. In few words, if the plan is to use a
new Class() approach, how about a mandatory Class definition Object ?
// the most basic Class implementation
function Class(
// Class definition object: mandatory
__proto__
) {
// define the "Class"
// if the definition object has a constructor property
var Class = __proto__.hasOwnProperty("constructor") ?
// use it ...
__proto__.constructor :
// otherwise create one and assign it
(__proto__.constructor = function () {})
;
Class.prototype = __proto__;
return Class;
}
// we already said that a Class is simply a function ...
Class.prototype = Function.prototype;
Above code is basically all we need to start using
new Class(definition) approach:
// class creation via definition object
var Person = new Class({
// this is our Person constructor
constructor: function (name) {
if (name) {
this.setName(name);
}
},
// this is a public property
name: "anonymous",
// this is a public method
setName: function (name) {
this.name = name;
}
});
Person instanceof Class; // true
Person instanceof Function; // ... as well
var dunno = new Person;
dunno instanceof Person; // true
dunno.name; // anonymous
dunno.constructor === Person; // true
I think this approach is as elegant as simple, but there is still a lot to consider about it.
A constructor IS An Implicit Init Method
I don't really know "when" it started and I am not sure about "why", but lots of libraries use this extra call to init/initialize/initializator/WTinitF method. If we think about this approach, it's like this:
// the JavaScript way
var a = [];
// the init way
var a = [];
a.init();
Now, think that for every created instance, rather than simply use the constructor for what it is, a method able to initialize an instance as is for basically every OOP language, we need to access to the instance chained prototype to execute
a second init ... not sure what you think about it, but this sounds a bit redundant to me ...
A Class constructor is already able to initialize an instance, that is simply why I have decided to be semantic and use just the constructor method as is rather than an extra init call.
A constructor Must Be Unique
The definition approach is something good in any case, but above implementation does not consider one of the best features in JavaScript: the context injection.
If we would like to reuse common methods, as example for a mixin or a hybrid prototype, initial suggestion is not enough.
The moment we use the same constructor to initialize a variable, we are already stuck. Even worst, we cannot reuse the same definition object to partially define one or more classes with common methods or initialization.
How to solve this? We need to chain the definition object in order to be able to extend the created
Class.prototype for everything we need.
// chained Class definition example
var Class = (function () {
// the public Class function
function Class(__proto__) {
// the created "Class"
function Class() {
// initialize the instance via original constructor
__proto__.constructor.apply(this, arguments);
}
// assign the prototype ...
Chain.prototype = __proto__ || (__proto__ = {});
// ... and create the chain, assigning the right constructor
Class.prototype = new Chain(Class);
return Class;
}
// runtime __proto__ chain with right constructor assignment
function Chain(Class) {
this.constructor = Class;
}
Class.prototype = Function.prototype;
return Class;
})();
We are still far away from a proper solution, at least we can now reuse a generic function to initialize one or more instances and we can reuse definition objects
var commonDef = {
constructor: function (name) {
if (name) {
this.name = name;
}
},
name: "unknown"
};
var Named = new Class(commonDef);
// this operation won't change commonDef object
Named.setName = function (name) {
this.name = name;
};
var Person = new Class(Named.prototype);
// this operation wont change Named.prototype
Person.prototype.getName = function () {
return this.name;
};
Thanks to prototype chain we are now able to extend directly another prototype, so that new Person, as example, will be instanceof Named too.
Don't Mix Class Definitions And Prototypes
While it could look good, the latter example has truly a bad design.
A Class definition should be a concept a part. If we use another Class.prototype to define a new Class we are mixing definitions with "defined" concept.
To extend or inherit from another object there must be a specific method.
To better explain myself, let's consider this simple PHP example:
class A {
// here we define the class
public function doStuff() {
}
}
class B extends A {
// we are extending another class
// but we are still defining here class B structure
public function __construct() {
}
}
If we pass directly a Class.prototype as definition, we are basically doing this, rather than what I have already showed:
class B extends A {}
Can we see the difference? B extends A and nothing else, there is no definition for B, everything is just like A.
OK, in JavaScript we can add and remove properties and methods from a prototype or a single instance in whatever moment, but aren't we trying to emulate somehow classic OOP paradigm? So let's agree that if we like this approach, prototypes must be untouchable after Class definition, and defined prototypes mustn't be used as Class definition ... do we agree?
Function.prototype.extend FAIL
I am the first one in error, I have tried to defined dunno how many times a proper Function.prototype.extend in order to make every function extensible.
The problem, specially in this case/approach, is that functions are functions, while Classes are Classes. If we make a generic "
extend" method available for any kind of function, even those never used to create instances, we are simply polluting without a valid reason a shared prototype: shared between classes and functions.
Moreover, the fact a Class is extending another one should be instantly recognizable, and not something that could happen in the middle of a generic session, do you agree?
In few words, some common approach is not truly readable/reasonable:
function B() {
// something happens here
};
// lazy extend, could happen everywhere
// even with functions such Math.max, kinda nonsense
B.extend(A);
B.prototype = {...};
// new Class pattern
var C = new Class({
// long definition object
})
// we need to scroll till the end to understand
// if C.prototype is chaining another one
.extend(B)
;
If we compare again with precedent PHP snippet, or every other OOP language where extends is basically the first thing we can understand about a class, I think nobody should ever use above pattern in JavaScript: it's cool, it's dynamic ... but it's absolutely wrong as well if we are trying to bring classic OOP approach into this language!
Only Explicit Extend Via Definition Object
At least for this topic, most common libraries are already implementing what I am talking about, which is something like this:
var Man = new Class({
// first thing ever into definition object
extend:Human,
// optional constructor ir simply
// the rest of the definition
gender:"male"
});
The fact extend must be explicit is simple: nobody should be able to pollute Object.prototype adding an extend method/property, if we recycle objects we don't want to extend automatically any inherited extend from internal chains.
Public Statics
Almost the last piece of the puzzle, the ability to add via definition public static properties or methods.
This could be another
special property name, used like this:
var File = new Class({
statics:{
exists:function (fileName) {
// some cool code here
return found;
}
},
constructor: function (fileName) {
this.name = fileName;
},
exists: function () {
return File.exists(this.name);
}
});
var fileName = "index.html";
var index = new File(fileName);
// it should be always true
File.exists(fileName) === index.exists();
Class.definition
I am trying to keep writing semantic code so I guess the last piece ever to add into the run-time created class is simply one: the definition object.
For both introspection and tricky code, I think it's a good idea to be able to retrieve the definition object. It could be reused, it could be analyzed, there are several things that could let us think:
how to get back that object?Well, since the extremely useful
__proto__ property is not standard, the only way to retrieve that object is to associate directly to the Class, being its definition, and via
definition property name. Is there anything more semantic and logic than this?
var def = {what:"ever"};
var MyClass = new Class(def);
MyClass.definition === def; // true
Now we can say we have everything!
this._super bullshit
Don't get me wrong, I do appreciate the effort every framework is putting in order to have a nice way to retrieve a super method, if any, but what we need to understand is that:
- _super, parent, whatever it is, requires to be portable for each parent "level", not just one
- to make first point possible, _super requires a lot of initial parsing, wrapping, and runtime substitutions, an inevitable performances bottleneck, as showed in my old tests
- wrappers are anonymous and all equals, almost impossible to debug
- wrappers could fail, causing disasters if the "super" does not fallback into the original one for that level
- try catch for super are performances killers, at the same time the best way to avoid disasters
- wrappers could cause infinite loops, if super is not handled properly
- super/parent is not an instance related property!!!
The latter point is the one that should suggest us to think about "super" misconception.
In classical OOP the super/parent keyword is related to the current method, it is
never an instance property.
When we need "super" we are talking about the super definition of the overridden method, if any, or another one up to the initial ring of the prototypal chain.
In few words, super has nothing to do with the instance, but for JavaScript nature, the simplest way to change runtime its reference, is to attach it to the instance.
Last, but not least, I have personally encountered problems, dunno how many times, with a whole stack or
super wrappers without being able to understand
which method was failing and where!
I am pretty sure that developers perfectly know what I am talking about, so while
this._super can be "cool", have we never thought how much better explicit injections could be?
var A = new Class({
doStuff: function () {
this.where = "A";
}
});
var B = new Class({
extend:A,
doStuff: function () {
// zero ambiguity, zero wrappers
// best performances + fast debug
A.prototype.doStuff.call(this);
// if some error occurs here
// we know where it did, rather than a wrapper
this.where += "B";
}
});
Furthermore, while in classic OOP super/parent is usable for
properties as well, I have never seen a proper implemntation for this in any framework.
As summary, while "super" or "parent" is something truly natural for classic OOP developers, there is no easy way to implement it properly in JavaScript, specially because if the same function can be used as method for 3 different classes, as example, the keyword super there will completely lose its meaning, basically the reason the only way to implement it, is to attach, substitute, and execute, runtime, via instances, rather than proper methods definition lookups. This is why my Class implementation does not provide such problematic "solution" for lazy developers.
WebReflection Class
var Class = (function () {
/*!
* JavaScript meaningfull Classic OOP Class Factory
* @author Andrea Giammarchi
* @license Mit Style
*/
/**
* Public exposed Class function
* @param Object the Class definition
*/
function Class(definition) {
// create the function via named declaration
function Class() {}
// find out if this is an extend
var $extend = hasOwnProperty.call(definition, "extend");
// temporary shortcut for inherited statics
var $;
// reassign the Class if there is a constructor ...
if (hasOwnProperty.call(definition, "constructor")) {
// wrapping it for faster execution
Class = constructor(definition.constructor);
}
// assign inherited public static properties/methods, if defined in the extend definition
if (
$extend &&
hasOwnProperty.call($ = definition.extend, "definition") &&
hasOwnProperty.call($ = $.definition, "statics")
) {
extend.call(Class, $.statics);
}
// assign public static properties/methods, if defined
// eventually overwrite inherited statics
if (hasOwnProperty.call(definition, "statics")) {
extend.call(Class, definition.statics);
}
// assign the prototype accordingly with extend
($extend ?
// chain the prototype extending it with the definition object
extend.call(Class.prototype = create(definition.extend.prototype), definition) :
Class.prototype = create(definition)
)
// be sure the constructor is the right one
.constructor = Class
;
// static public definition
Class.definition = definition;
// return the created class
return Class;
}
// wrap the constructor via closure
function constructor(constructor) {
// creating a named declared Class function
function Class() {
// return in any case for dual behaviors (factories)
return constructor.apply(this, arguments);
}
return Class;
}
// extend a gneric context via __proto__ object
function extend(__proto__) {
for (var key in __proto__) {
if (hasOwnProperty.call(__proto__, key)) {
this[key] = __proto__[key];
}
}
return this;
}
// trap the original Object.prototype.hasOwnProperty function
// as shortcut and hoping nobody changed it before this file inclusion ...
var hasOwnProperty = Object.prototype.hasOwnProperty;
// quick/fast Object.create emulator, if not in ES5
var create = Object.create || (function () {
function Object() {}
return function (__proto__) {
Object.prototype = __proto__;
return new Object;
};
})();
//* optional standard "for in" for Internet Explorer
// it could be removed if we don't define "magic mathods" in definition objects
// Internet Explorer does not enumerate properties/methods
// with name present in the Object.prototype
if (!({toString:null}).propertyIsEnumerable("toString")) {
// if this happens, to make the extend consistent
// we need to force Object.prototype names
extend = (function ($extend) {
function extend(__proto__) {
for (var i = length, key; i--;) {
if (hasOwnProperty.call(__proto__, key = split[i])) {
this[key] = __proto__[key];
}
}
// execute the original extend in any case for other properties/methods
return $extend.call(this, __proto__);
}
// constructor is not in the list since there is a re-assignment in any case
var split = "hasOwnProperty.isPrototypeOf.propertyIsEnumerable.toLocaleString.toString.valueOf".split(".");
var length = split.length;
return extend;
})(extend);
}
//*/
// a Class is a Function and nothing else
Class.prototype = Function.prototype;
return Class;
})();
A simple test case:
var A = // base class
new Class({
constructor: function () {
alert("A");
},
toString: 123
})
;
var B = // extended class
new Class({
extend:A,
constructor: function () {
A.call(this);
alert("B");
},
toString: 4
})
;
var b = new B;
// 4, true, true, true in every browser
alert([b.toString, b instanceof A, b instanceof B, b.constructor === B]);
Personal Thoughts
What I don't like is that extend, as statics, become part of the prototype as well. Unfortunately I decided that these words should be kinda
reserved in order to speed up Classes creation.
At the same time, Classes creation is something performed once and never again, so I may decide to change in the future the way I define the prototype, simply looping via "for in" and attaching properties. This could cause some sort of problem with truly inherited stuff, so right now I guess this is it.
As Summary
My Class implementation does not probably bring anything new in the panorama but what it does, it does it properly. The definition object has precedence over inherited properties/methods. Super or extra methods calls should be explicit, avoiding redundant wrappers, improving performances, and making debug easier. Constructors, if present, are used as instance initializers, as it has always been in classic OOP. Every definition could be wrapped in a closure and returned, in order to have shared private properties or methods and Classes are finally instanceof Class, or better, are simply functions.