WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread David Bruant
Hi, There seems to be a consensus on bringing in WeakRefs in the language. I came around to the idea myself as some use cases seem to require it (as in: some use cases can't be achieved even with a .dispose convention like distributed acyclic garbage collection). However, I worry. Recently,

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread K. Gadd
If memory serves, http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.htmlwas also complaining about a similar closure/scope leak in v8 where locals that you wouldn't expect to be retained are retained by closures in some cases. Arguably those cases just need to be fixed.

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread David Bruant
Le 27/07/2013 18:22, K. Gadd a écrit : Of course, I don't know how difficult it actually is to fix this. Difficulty is obviously one major concern. If this was easy to fix, I imagine it would have already been done; JS engine maintainers don't keep easy-to-fix leaks for fun. Also, apparently,

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread David Bruant
Le 27/07/2013 20:27, Brendan Eich a écrit : Weak refs are necessary for observer patterns, as we've discussed ad nauseum. That's not the conclusion I took from these discussions. As I feel words are important, the conclusions I took are: WeakRefs are *necessary* for distributed acyclic garbage

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread Brendan Eich
David Bruant wrote: Le 27/07/2013 20:27, Brendan Eich a écrit : Weak refs are necessary for observer patterns, as we've discussed ad nauseum. That's not the conclusion I took from these discussions. As I feel words are important, the conclusions I took are: WeakRefs are *necessary* for

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread David Bruant
Le 28/07/2013 01:11, Brendan Eich a écrit : with confirmation from Rafael Weinstein: https://mail.mozilla.org/pipermail/es-discuss/2013-March/028918.html This is exactly right. let's quote a bit more from the same message: Without WeakRefs, observation will require a dispose() step in order

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread Brendan Eich
David Bruant wrote: Each view and each model has some other object (maybe another view or model or maybe some other object) that created it and bound it respectively to a model or a view (or several). This creator/binder (doesn't need to be unique for all objects and most likely isn't) takes

Re: WeakRefs leading to spec-imposed memory leaks?

2013-07-27 Thread David Bruant
Le 28/07/2013 03:15, Brendan Eich a écrit : David Bruant wrote: Each view and each model has some other object (maybe another view or model or maybe some other object) that created it and bound it respectively to a model or a view (or several). This creator/binder (doesn't need to be unique

RE: More concise arrow functions

2013-07-27 Thread Nathan Wall
Why do arrow functions require a parameter list and a body? That is, none of the following are allowed: - `= foo` - `bar =` - `=` Instead you need the more-verbose - `() = foo` - `bar = {}` - `() = {}` Any chance of relaxing this a bit? +1

Re: More concise arrow functions

2013-07-27 Thread Axel Rauschmayer
+1 My perspective: I don’t see a use case for a missing body, but a missing parameter list would be very useful – to delay the execution of a block of code. It also makes much sense visually: 2. (x, y) = { ... } 1. x = { ... } 0. = { ... } On Jul 26, 2013, at 22:11 , Brandon Benvie

RE: More concise arrow functions

2013-07-27 Thread Domenic Denicola
I agree a missing body is usually weird; the only case that really makes sense is `=`, which is especially useful in default parameter lists: ```js function tryCatchFinally(tryF, catchF = =, finallyF = =) { // ... } ``` From: Axel

Re: More concise arrow functions

2013-07-27 Thread Axel Rauschmayer
This is full-on bikeshedding, but I’d prefer a constant for this purpose (less grawlixy): ```js import { NOOP } from 'someModule'; function tryCatchFinally(tryF, catchF = NOOP, finallyF = NOOP) { // ... } ``` function.prototype could be used, too. But I don’t like that at all. On Jul 28,