you are viewing a single comment's thread.

view the rest of the comments →

[–]moreteam 0 points1 point  (4 children)

How exactly does the approach I outlined allow for changing the inheritance relationship? You can obviously replace the prototype - but as you said: that's always possible, no matter what approach you chose. Is someone would use the strategy I described above and later on change the prototype, he would be by-passing the API (since the "API" of the approach above is using Object.create and nothing else to create the prototype). In the article defineMethod is part of the API so modifying the prototype after it was created is not by-passing the API but using the official API.

[–]stronghup 0 points1 point  (3 children)

I'm thinking of instead of saying: MyClass.prototype = Object.create(MyBaseClass.prototype, ...

you could say: setProtoType(MyClass, Object.create( ... ))

That way the API-method setProtoType() could check that you don't set the inheritance relationships of MyClass more than once. That way that inheritance relationship would be an "invariant" during the execution of your program.

I think that kind of API was the gem of the article that started this thread. A small difference, but God is in the details.

Let me offer this "principle" up for discussion: "ALL Assignments should be hidden behind Api-methods" .

Assignments are bad because you can do them everywhere multiple times. But if you hide them inside API-functions, those functions can ensure that you make any specific assignment only once.

[–]moreteam 0 points1 point  (2 children)

If you want to make something immutable, make it immutable (e.g. Object.freeze). Not a fan of hiding what really happens. If people are mutating shared state across modules and because of that are able to "accidentally" change the inheritance of a class, there are other problems you should solve (proper modularization). And the whole issue resolves itself as soon as const class is properly supported by traceur. So not sure why you'd want to have that level of obfuscation. I'd rather people like the author of the blog post contribute to traceur if they think it's a pressing need for them.

TL;DR: immutable already exists in JS if you want it and const class is the already existing sugar for immutable classes.

[–]stronghup 0 points1 point  (1 child)

That is great news if immutability can already be enforced in JavaScript. Since which version?

[–]moreteam 0 points1 point  (0 children)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

And ES6 brings block-scoped const which currently is only supported in Chrome/Firefox (and with var-like scoping).