Comment by AnEngineer | Hacker News Reader

Comment by AnEngineer | Hacker News Reader

Parent Full thread

I believe what you describe can be also described as performing a shallow copy on the prototype which includes the entries from previous copies of the hash map referenced in prior statements.

Unless what transpires is a "back link" to prior definitions such that additions to those prototypes are reflected in subsequent references. Quite frankly, I don't recall off the top of my head which way compliant EMCAScript implementations behave.

> This is very different then a dictionary, where you now have the ability to 'shadow' a property or to change the value of a key in a prototype and have it reflected in all children (which is the exact opposite of a shallow copy).

A dictionary which is shared across all instances would reflect this behaviour, true, but when a dictionary's contents are copied, changes made to the source would not be reflected in the copy (for "first level" key value pairs). I'm pretty sure that adding an indirection to a JavaScript prototype definition (such as placing a hash map in the prototype) would have _its_ key value pairs shared across instances.

But I could very easily be wrong about that.

> Unless what transpires is a "back link" to prior definitions such that additions to those prototypes are reflected in subsequent references. Quite frankly, I don't recall off the top of my head which way compliant EMCAScript implementations behave.

It is:

    var a = {}; var b = {__proto__: a}; console.log(b.x); a.x = 5; console.log(b.x);

(prints undefined then 5)

There are some other points that you are missing, like how do constructors work? If JS objects are just glorified hash maps, why can I write a constructor function to do some stuff when the object is instantiated? The object literal syntax that looks very much like the "hash map" you are describing is exactly the same as creating a new object that extends the Object prototype. In fact, that's pretty much what's going on when you type `{}`.

JavaScript is absolutely an object-oriented programming language, but it's unusual because it's also pseudo-functional, in that functions are first-class citizens. However, functions are also objects. When you type `function` in JS, that is generating an object with the `Function` prototype. You can extend this prototype and call methods on `Function`. That's how Ember.js makes its computed property syntax work, so you can just tack on `.property()` to the end of your function. This would not be possible if JS worked given the semantics you described, because in that story a function is just a function, and not an entire object. JS hides these gory details from you to simplify your experience. Most of the time, you shouldn't have to worry about these kinds of things, but it's fascinating to learn about because there's no other language that works quite like JS.

> If JS objects are just glorified hash maps, why can I write a constructor function to do some stuff when the object is instantiated?

There's no big reason for that, and Object.clone doesn't give that hook, you have to use a wrapper function instead.

> JavaScript is absolutely an object-oriented programming language, but it's unusual because it's also pseudo-functional, in that functions are first-class citizens.

What's unusual about that?

> it's fascinating to learn about because there's no other language that works quite like JS.

That can be said about pretty much any and every language out there.

Reply on news.ycombinator.com