Repository navigation
Cool idea! #2
Description
Activity
That's funny, I just committed to a new branch that does the same mutable
"hack" since you can't overload. I'll have to check yours out!
On Thu, Aug 4, 2016 at 18:00 Boris Cherny notifications@github.com wrote:Hey there!
I had a similar idea a while ago, but realized that without operator
overloading this isn't a complete abstraction. Eg.import {Map} from 'immutable-proxy'
const a = new Map({b: 1})a.b = 2assert(a.b == 2) // this just mutated a!If we had operator overloading, we could do this, though it feels strange
in JS:import {Map} from 'immutable-proxy'
const a = new Map({b: 1})const b = a.b = 2assert(a.b == 1)assert(b.b == 2)assert(a != b)Anyway, I ended up with this proof of concept:
https://github.com/bcherny/auditable - mutable datatypes, backed by
immutable data structures.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAbacKrxzumVWOYDEkZyn3eBw1YhOiNWks5qcmEGgaJpZM4JdKkf
.Hey guys! Wouldn't it be better just to deny in any direct set operations? I mean, this code should throw a
TypeError: Direct data changes are prohibited, use .set()!import {Map} from 'immutable-proxy' const a = new Map({b: 1}) a.b = 2const b = a.b = 2feels very strange in JS and I bet it'd frighten most of users right away as it feels too much unnatural. However, a complete restriction of the set operations seems to be a rigid and, which is the most important`, a very practical way. All in all, the whole point of immutability is to put restrictions on the developer to avoid complexities and a whole subset of potential bugs.What do you think?
Reacted by Dmytro Getmantsovconst b = a.b = 2feels very strange in JSI agree - that's why the abstraction is incomplete. Keep in mind that since JS does not have operator overloading, the above is actually impossible to implement without a macro or some other language extension.
If you are OK with a less specific error message, you can implement your TypeError without Proxies:
const map = Object.freeze(new Immutable.Map) map[2] = 3 // Error!
That would actually be a good idea! I am up for changing it to throw an
error.On Mon, Sep 12, 2016 at 1:44 PM Boris Cherny notifications@github.com
wrote:const b = a.b = 2 feels very strange in JS
I agree - that's why the abstraction is incomplete. Keep in mind that
since JS does not have operator overloading, the above is actually
impossible to implement without a macro or some other language extension.If you are OK with a less specific error message, you can implement your
TypeError without Proxies:const map = Object.freeze(new Immutable.Map)
map[2] = 3 // Error!—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbacIFJTOUdGELNSWhqbhAqZKDhhYTAks5qpY97gaJpZM4JdKkf
.
Hey there!
I had a similar idea a while ago, but realized that without operator overloading this isn't a complete abstraction. Eg.
If we had operator overloading, we could do this, though it feels strange in JS:
Anyway, I ended up with this proof of concept: https://github.com/bcherny/auditable - mutable datatypes, backed by immutable data structures.