> Yehuda's "action at a distance" complaint is definitely a valid
> concern. However, note that an object can't be freed unless you have
> a reference to the object. Thus, any code that would set my reference
> to undefined could only do so if it was also capable of mutating the
> object in any other way (adding/removing properties, etc.)
>
> So, we already have this:
>
> function () {
> // acquire a ref from some external code
> // no way of knowing what else is sharing this object
> var x = func()
> x.foo = 'bar'
> // other code...
> doAnotherThing()
> // not guaranteed!
> assert(x.foo === 'bar')
> }
>
> Whenever you have a reference to an object that is shared with some
> other code, there's the potential for action at a distance. The
> proposal here is to make that action a bit more powerful.
JavaScript is mutable enough. I wouldn't want this anywhere near my code or
any library I ever used. It completely removes control from someone writing
code. Yes, mutation is possible now, but numbers, boolean, and strings are
not, and you can freeze and object if you want to. You said yourself that
the problem is with the code that is doing the leaking. Better tools to fix
your code is a nice addition, but adding an operator like this has the
potential to add weird bugs all over. If you're only working on your own
code base, maybe a tool like this is fine, shoot yourself in the foot, but
in an eco-system of sharing packages and libraries, etc. this is just more
ammunition to bad practice. If you are skilled enough to know the right
time to use an operator like this, you're skilled enough to fix your code.
If its hard to fix, tools could surely assist.
- Russ
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
