It is:
var a = {}; var b = {__proto__: a}; console.log(b.x); a.x = 5; console.log(b.x);
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.
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.
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.