It's a bit sad that one of the most useful cases for `Object.create` was not covered: it is the only way to create an object without a prototype. Using constructor functions, even if you explicitly set the ``prototype`` to ``null``, instances's ``__proto__`` remains ``Object.prototype``:
> var F = function () {};
> F.prototype = null;
null
> (new F).__proto__ === Object.prototype;
true
This means all the "default" object methods are there (e.g. #hasOwnProperty) and ready to get clobbered with all the risk it entails[0].
With ``Object.create(null)``, however, the __proto__ of the created object is effectively ``null``:
> Object.create(null).__proto__
null
and such pesky methods as #hasOwnProperty or #toString are not there for clobbering.
And an issue of Object.create failed to be mentioned as well: you can't use ``instanceof`` directly, you have to create one-off "constructor functions" to call ``instanceof`` on them.
I appreciate the post, but the typical reaction to these articles seems to be:
- JavaScript looks a bit like (Java/Ruby/other language)
- JavaScript does not work like (said language)
- JavaScript sucks
Granted, I appreciate folks pointing out the "bad parts" of the language and the strange gotchas. And JavaScript has more than its share of bad parts. But it also requires a change in mindset. At minimum, expect
- a priority of first-class functions,
- Prototypal rather than classical inheritance,
- time spent learning JavaScript syntax itself instead of constructs from other languages (which often will work, but not in the way expected).
Books that have given me a renewed appreciation are Douglas Crockford's book (JavaScript the Good Parts) and John Resig's "Secrets of the JavaScript Ninja."
Meh. Javascript looks, feels and behaves much more like a single-inheritance class-based language (without the class sugar) than like a prototype-based one (Io and even more so Self). Especially if you stick to the standard.
A small concession was made towards prototypal use in ES5 with Object.create (which remains little used and slow as molasses) but it's looking to snap back to classes with ES6
ES6 will introduce class syntax, but it's also going to standardise __proto__ property [1] making it easier to write both classical and prototypical code.
"use strict";
var square = {length:10};
Object.freeze(square);
square.length = 20;
C:\Users\Matt\Code\seal.js:5
square.length = 20;
^
TypeError: Cannot assign to read only property 'length' of #<Object>
at Object.<anonymous> (C:\Users\Matt\Code\seal.js:5:15)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
I haven't found a use for a lot of these features, a lot of them just seem very ad-hoc additions to the language. A class based object oriented model would have solved a lot of issues relating to the myriad ways to implement object orientation in javascript. The schizophrenic like approach we have right now isn't being helped by incremental changes driven by the lowest common denominator of what can be implemented in a web browser development cycle.
Many of the additions (including object.freeze) and changes were made for the purpose of making JavaScript usable as an object capability language. Mark Miller explains the background and some of the changes in the video linked above.
When you do "var B = Object.create(A);", should B be called a clone of A or a copy of A?
I have seen various definitions of the term "clone", e.g. Io language documentation says that "a clone is an empty object that has the parent in its list of protos", this article defines clone as an exact shallow copy of another object.
> When you do "var B = Object.create(A);", should B be called a clone of A or a copy of A?
Neither. In Self lingo, A is a mixin of B. The least bad wording would be centered around composition, but I guess it could also be understood that B is an extension of A.
It can't be a clone or a copy, because changing A will still impact B, they don't become independent objects.
With ``Object.create(null)``, however, the __proto__ of the created object is effectively ``null``:
and such pesky methods as #hasOwnProperty or #toString are not there for clobbering.And an issue of Object.create failed to be mentioned as well: you can't use ``instanceof`` directly, you have to create one-off "constructor functions" to call ``instanceof`` on them.
[0] http://www.devthought.com/2012/01/18/an-object-is-not-a-hash...