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,
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.
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,
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
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
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
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
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
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
+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
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
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,
12 matches
Mail list logo