Cool idea!

[bcherny]

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 = 2
assert(a.b == 2) // we 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 = 2
assert(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.

[zackify]

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
.

[kirillrogovoy]

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 = 2

const b = a.b = 2 feels 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?

[bcherny]

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!

[zackify]

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
.