

Revisiting JavaScript Objects - laktek
http://www.laktek.com/2012/12/29/revisiting-javascript-objects

======
masklinn
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.

[0] [http://www.devthought.com/2012/01/18/an-object-is-not-a-
hash...](http://www.devthought.com/2012/01/18/an-object-is-not-a-hash/)

------
EzGraphs
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."

~~~
masklinn
> \- Prototypal rather than classical inheritance,

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

~~~
jarek-foksa
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.

[1]
[http://javascript.spec.whatwg.org/#object.prototype.__proto_...](http://javascript.spec.whatwg.org/#object.prototype.__proto__)

------
RyanZAG
I just can't like javascript, and it's the design idea behind stuff like this
that causes it:

    
    
      > Object.freeze(square);
      > square.length = 20
        20 
      > square.length
        10
    

square.length = 20 should be throwing an error. No excuses, sane defaults.

~~~
quarterto
It throws an error in strict mode.

    
    
        "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)

------
cpleppert
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.

Knowing the [Good Parts]([http://www.amazon.com/JavaScript-Good-Parts-Douglas-
Crockfor...](http://www.amazon.com/JavaScript-Good-Parts-Douglas-
Crockford/dp/0596517742)) helps but you just can't keep adding parts that you
think may be good.

~~~
thingification
Here is the context that makes these features not seem ad hoc:

[http://www.infoq.com/interviews/ecmascript-5-caja-
retrofitti...](http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-
security)

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.

------
jarek-foksa
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.

~~~
masklinn
> 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.

