Re: Weak event listener
I've been through the thread and I haven't read any use case that *requires* Weak References. Only use cases where they make life easier to various degrees. It's been agreed that in most cases, adding an explicit .dispose() or equivalent protocol could work too. Very few things added to ES6 is *required*, most of them makes the life of developers easier. Some of them only slightly improves our life (default variables, spreading, etc), while others change the way projects are structure (modules, classes, etc). WeakRefs would be such a feature. The use of WeakRefs instead of a .dispose() method is a major improvement in workflow, and allows some very interesting projects and data structures. As Kevin said: A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does... This is a concept which cannot be expressed in JavaScript today, but which most code actually needs to hint at in some way. Most objects are owned by one other object, and known by many other objects. The objects which knows of it shouldn't keep it alive, only the owner should. It is impossible to distinguish between these two cases in JavaScript today. An example of this would be a GUI with event listening widgets, which is usually a tree where each widget is owned by its parent, and a widget without a parent should stop listening to events. There are many ways to implement this without WeakRefs, usually involving an explicit _parent_ field and a dispose method when a widget is removed. But with WeakRefs this could be implemented so only the parent has a strong reference to the children, everyone else has weak references and so the widget (and all its children) are garbage collected and stop listening to events when the parent deletes it. Hopefully this is enough of a usecase to make WeakRefs (or one of the alternatives, for example, an iterable set of weak references to functions/objects). Marius Gundersen On Wed, Apr 3, 2013 at 6:40 AM, Kevin Gadd kevin.g...@gmail.com wrote: An important distinction here - and one I think Bill and Brendan and others have gotten at some, and I've been trying to get at - is that weak references (and similar concepts, like weak maps and weak event listeners) unfortunately encompass a set of different problems and end up being used to solve some (or all) of them in different contexts. Resource management in the traditional 'memory and handles' sense is one of these contexts. History has, at this point, pretty much proven that you don't need a garbage collector to manage resources, but it has also pretty much proven that having one really helps. JS's garbage collector is a real win for ease of use (and safety, as Bill points out) in this area, but in practice JS rarely actually manipulates raw memory or handles to the extent that weak references are sorely needed. In cases where WRs are sorely needed, as well, the payoff is often significant enough to justify just going through and manually filling your code with calls to .dispose(). I've certainly done it dozens of times, and with enough discipline and process even big teams with junior programmers can manage it. The context that motivates me to beg and plead for WRs, though, is a different one: Architecture and 'state management', so to speak, where the liveness of an object has real, semantic meaning beyond whether the memory that holds it has been freed and whether the object is reachable. The example I gave of an application with 'modes' is one of the best examples of this I've run into in my career, because it was a huge problem that kept tripping us up as we maintained and extended the application - being able to say at any point whether a mode needed to be alive, and whether its associated resources and event listeners needed to be alive, was a really big challenge. In some situations we solved this with explicit disposal, but in other situations we *absolutely* needed Weak References to keep things sane, and going through and manually breaking cycles and removing event listeners and nulling parent references simply would not have been scalable. Even our best programmers wouldn't have been able to do it consistently. A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does - is really hard (for me, at least) to convey through design/comments and enforce manually with code. Having the aid of the type system and the runtime here is a huge boon. This is why the 'build your own malloc'/'build your own collector'/'do manual refcounting' solutions feel like a poor choice to me. Those solutions do a great job of solving resource management problems, because you can apply the cold unfeeling gaze of computer science to
Re: Weak event listener
On Wed, Apr 3, 2013 at 2:13 AM, Marius Gundersen gunder...@gmail.comwrote: I've been through the thread and I haven't read any use case that *requires* Weak References. Only use cases where they make life easier to various degrees. It's been agreed that in most cases, adding an explicit .dispose() or equivalent protocol could work too. Very few things added to ES6 is *required*, most of them makes the life of developers easier. Discussing whether weakrefs are required and for what is good. But please keep in mind that we're discussing ES7. It is way too late to add something like this to ES6. Some of them only slightly improves our life (default variables, spreading, etc), while others change the way projects are structure (modules, classes, etc). WeakRefs would be such a feature. The use of WeakRefs instead of a .dispose() method is a major improvement in workflow, and allows some very interesting projects and data structures. As Kevin said: A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does... This is a concept which cannot be expressed in JavaScript today, but which most code actually needs to hint at in some way. Most objects are owned by one other object, and known by many other objects. The objects which knows of it shouldn't keep it alive, only the owner should. It is impossible to distinguish between these two cases in JavaScript today. An example of this would be a GUI with event listening widgets, which is usually a tree where each widget is owned by its parent, and a widget without a parent should stop listening to events. There are many ways to implement this without WeakRefs, usually involving an explicit _parent_ field and a dispose method when a widget is removed. But with WeakRefs this could be implemented so only the parent has a strong reference to the children, everyone else has weak references and so the widget (and all its children) are garbage collected and stop listening to events when the parent deletes it. Hopefully this is enough of a usecase to make WeakRefs (or one of the alternatives, for example, an iterable set of weak references to functions/objects). Marius Gundersen On Wed, Apr 3, 2013 at 6:40 AM, Kevin Gadd kevin.g...@gmail.com wrote: An important distinction here - and one I think Bill and Brendan and others have gotten at some, and I've been trying to get at - is that weak references (and similar concepts, like weak maps and weak event listeners) unfortunately encompass a set of different problems and end up being used to solve some (or all) of them in different contexts. Resource management in the traditional 'memory and handles' sense is one of these contexts. History has, at this point, pretty much proven that you don't need a garbage collector to manage resources, but it has also pretty much proven that having one really helps. JS's garbage collector is a real win for ease of use (and safety, as Bill points out) in this area, but in practice JS rarely actually manipulates raw memory or handles to the extent that weak references are sorely needed. In cases where WRs are sorely needed, as well, the payoff is often significant enough to justify just going through and manually filling your code with calls to .dispose(). I've certainly done it dozens of times, and with enough discipline and process even big teams with junior programmers can manage it. The context that motivates me to beg and plead for WRs, though, is a different one: Architecture and 'state management', so to speak, where the liveness of an object has real, semantic meaning beyond whether the memory that holds it has been freed and whether the object is reachable. The example I gave of an application with 'modes' is one of the best examples of this I've run into in my career, because it was a huge problem that kept tripping us up as we maintained and extended the application - being able to say at any point whether a mode needed to be alive, and whether its associated resources and event listeners needed to be alive, was a really big challenge. In some situations we solved this with explicit disposal, but in other situations we *absolutely* needed Weak References to keep things sane, and going through and manually breaking cycles and removing event listeners and nulling parent references simply would not have been scalable. Even our best programmers wouldn't have been able to do it consistently. A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does - is really hard (for me, at least) to convey through design/comments and enforce manually with code. Having the aid of the type system and the runtime here is a huge
Re: Weak event listener
Le 03/04/2013 11:13, Marius Gundersen a écrit :
A core part of the problem here is that the distinction between an
'important' reference - one that must keep an object alive - and an
'incidental' reference, that only need exist as long as it target does...
This is a concept which cannot be expressed in JavaScript today, but
which most code actually needs to hint at in some way. Most objects
are owned by one other object, and known by many other objects. The
objects which knows of it shouldn't keep it alive, only the owner
should. It is impossible to distinguish between these two cases in
JavaScript today.
It is possible to make /a/ distinction with proxies. More specifically,
with revocable proxies [1]
let { proxy, revoke } = Proxy.revocable(target, handler);
proxy.foo // traps
revoke()
proxy.foo // throws TypeError: proxy is revoked
Let's create a small abstraction on top of that:
function RevocableRef(target){
var transparentHandler = {};
return Proxy.revocable(target, transparentHandler);
}
You can keep the original target and the revoke function to yourself and
decide only to share RevocableRefs of the object (which is pretty much
the equivalent of wrapping with the WeakRef constructor).
When you don't want others to access the object anymore, just call the
revoke function.
It is one way to make a distinction between different references to the
same object and keep control of who has access to which object at what time.
An example of this would be a GUI with event listening widgets, which
is usually a tree where each widget is owned by its parent, and a
widget without a parent should stop listening to events. There are
many ways to implement this without WeakRefs, usually involving an
explicit _parent_ field and a dispose method when a widget is removed.
But with WeakRefs this could be implemented so only the parent has a
strong reference to the children, everyone else has weak references
and so the widget (and all its children) are garbage collected and
stop listening to events when the parent deletes it.
In that case, it seems that only the parent would keep a strong
reference to a child widget and hand over a RevocableRef to other
parties. When detaching the child widget, the parent would just need to
call the revoke function.
I admit this is more work than just detaching the child, but it is not a
huge amount (calling one function). More interestingly, all the control
of references remains at the parent level, that is, the parent decides
which type of reference is shared (a revocable one or not); no need for
third-parties to comply to a dispose protocol, where different parties
have to dispose, sometimes recursively which can be a mess.
The idea of being able to differentiate references is interesting, but
doesn't seem to justify the non-determinism that comes with WeakRefs. It
sounds that what we already have (revokable proxies and the RevocableRef
abstraction above) would be enough in the use case you described (and
Kevin's use case too from what I understand).
If I misunderstood any of your (Kevin and Marius) use cases, could you
explain what would be the added value of WeakRefs over revokable proxies.
Do languages which added WeakRefs have a form of revokable reference
too? What difference would it make?
David
[1] http://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Wed, Apr 3, 2013 at 11:20 AM, David Bruant bruan...@gmail.com wrote:
Le 03/04/2013 11:13, Marius Gundersen a écrit :
A core part of the problem here is that the distinction between an
'important' reference - one that must keep an object alive - and an
'incidental' reference, that only need exist as long as it target does...
This is a concept which cannot be expressed in JavaScript today, but
which most code actually needs to hint at in some way. Most objects are
owned by one other object, and known by many other objects. The objects
which knows of it shouldn't keep it alive, only the owner should. It is
impossible to distinguish between these two cases in JavaScript today.
It is possible to make /a/ distinction with proxies. More specifically,
with revocable proxies [1]
let { proxy, revoke } = Proxy.revocable(target, handler);
proxy.foo // traps
revoke()
proxy.foo // throws TypeError: proxy is revoked
Let's create a small abstraction on top of that:
function RevocableRef(target){
var transparentHandler = {};
return Proxy.revocable(target, transparentHandler);
}
You can keep the original target and the revoke function to yourself and
decide only to share RevocableRefs of the object (which is pretty much the
equivalent of wrapping with the WeakRef constructor).
When you don't want others to access the object anymore, just call the
revoke function.
It is one way to make a distinction between different references to the
same object and keep control of who has access to which object at what time.
An example of this would be a GUI with event listening widgets, which is
usually a tree where each widget is owned by its parent, and a widget
without a parent should stop listening to events. There are many ways to
implement this without WeakRefs, usually involving an explicit _parent_
field and a dispose method when a widget is removed. But with WeakRefs this
could be implemented so only the parent has a strong reference to the
children, everyone else has weak references and so the widget (and all its
children) are garbage collected and stop listening to events when the
parent deletes it.
In that case, it seems that only the parent would keep a strong reference
to a child widget and hand over a RevocableRef to other parties. When
detaching the child widget, the parent would just need to call the revoke
function.
I admit this is more work than just detaching the child, but it is not a
huge amount (calling one function). More interestingly, all the control of
references remains at the parent level, that is, the parent decides which
type of reference is shared (a revocable one or not); no need for
third-parties to comply to a dispose protocol, where different parties
have to dispose, sometimes recursively which can be a mess.
The idea of being able to differentiate references is interesting, but
doesn't seem to justify the non-determinism that comes with WeakRefs. It
sounds that what we already have (revokable proxies and the RevocableRef
abstraction above) would be enough in the use case you described (and
Kevin's use case too from what I understand).
If I misunderstood any of your (Kevin and Marius) use cases, could you
explain what would be the added value of WeakRefs over revokable proxies.
Do languages which added WeakRefs have a form of revokable reference too?
What difference would it make?
E has both. In practice, my sense is that their use cases are disjoint, and
that both are needed.
David
[1]
http://wiki.ecmascript.org/**doku.php?id=strawman:**revokable_proxieshttp://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 03/04/2013 21:18, Mark S. Miller a écrit : Do languages which added WeakRefs have a form of revokable reference too? What difference would it make? E has both. In practice, my sense is that their use cases are disjoint, and that both are needed. Do you have examples of use? May be links to E code. In what way is the GC-notification mechanism really necessary? (that's the part that I'm personally annoyed with most). I would be much less bothered if weakrefs were in essence revocable references for which only the GC has the revoke function (called on GC of the underlying target). It seems it would already solve the use cases exposed on the list which (my summary) Kevin expressed as A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does Whatever final form is chosen (and even if weakrefs are only for ES7), would it make sense to unify what a revoked proxy and a dead weakref look like? Both look very close in what they are. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Wed, Apr 3, 2013 at 1:10 PM, David Bruant bruan...@gmail.com wrote: Le 03/04/2013 21:18, Mark S. Miller a écrit : Do languages which added WeakRefs have a form of revokable reference too? What difference would it make? E has both. In practice, my sense is that their use cases are disjoint, and that both are needed. Do you have examples of use? May be links to E code. In what way is the GC-notification mechanism really necessary? (that's the part that I'm personally annoyed with most). I would be much less bothered if weakrefs were in essence revocable references for which only the GC has the revoke function (called on GC of the underlying target). It seems it would already solve the use cases exposed on the list which (my summary) Kevin expressed as A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does Whatever final form is chosen (and even if weakrefs are only for ES7), would it make sense to unify what a revoked proxy and a dead weakref look like? Both look very close in what they are. The main use of weakrefs in E is indeed related to proxies, but not in the way you may expect. Weakrefs are used to implement CapTP's distributed acyclic garbage collector. An E remote-reference-proxy is used as the local representative of a remote object. Though such E proxies are more like Q/ES7 promises than like ES6 proxies. A weakref is used to determine when there is no longer any local need for a reference to that remote object. When this is detected, the local vat sends a message (GCExportOp and GCAnswerOP at http://erights.org/elib/distrib/captp/DeliverOp.html#step9) to the remote vat so the remote vat can clean up its corresponding incoming tables. A captp-like protocol for distributed Q should make use of the same technique, but won't be able to until we add weakrefs to ES7. Until then, Q will leak a tremendous amount of distributed acyclic cross-vat garbage. David -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On 4/1/13 at 5:40 AM, sa...@ccs.neu.edu (Sam Tobin-Hochstadt) wrote: Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. There are a bunch of different reasons for wanting to dispose an object in memory. With the malloc/free system from C, you usually dispose objects to recover their backing memory for future use. The C version is not memory safe. If you are paying for the memory, you may be willing to break things to be able to stop paying. There may be some other reasons for causing an object to stop working and as a side effect recover most of its memory. A proxy can provide this service for JS, along with a number of other techniques all of which will be memory safe. For short-lived programs, you can ignore memory disposal if the system running them will free the memory when they exit. This technique is memory safe and even works with mismanagement of references in a garbage collected systems. Having a system which supports just exiting and recovering memory is valuable for ad-hoc programming environments. It might also be valuable for ads running in long-lived web pages. Possibly some of the safe JS execution environments provide this service for the programs they mediate. Memory safety is one really good reason to choose JS over C. Cheers - Bill --- Bill Frantz| The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself. - FDR | 16345 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
An important distinction here - and one I think Bill and Brendan and others have gotten at some, and I've been trying to get at - is that weak references (and similar concepts, like weak maps and weak event listeners) unfortunately encompass a set of different problems and end up being used to solve some (or all) of them in different contexts. Resource management in the traditional 'memory and handles' sense is one of these contexts. History has, at this point, pretty much proven that you don't need a garbage collector to manage resources, but it has also pretty much proven that having one really helps. JS's garbage collector is a real win for ease of use (and safety, as Bill points out) in this area, but in practice JS rarely actually manipulates raw memory or handles to the extent that weak references are sorely needed. In cases where WRs are sorely needed, as well, the payoff is often significant enough to justify just going through and manually filling your code with calls to .dispose(). I've certainly done it dozens of times, and with enough discipline and process even big teams with junior programmers can manage it. The context that motivates me to beg and plead for WRs, though, is a different one: Architecture and 'state management', so to speak, where the liveness of an object has real, semantic meaning beyond whether the memory that holds it has been freed and whether the object is reachable. The example I gave of an application with 'modes' is one of the best examples of this I've run into in my career, because it was a huge problem that kept tripping us up as we maintained and extended the application - being able to say at any point whether a mode needed to be alive, and whether its associated resources and event listeners needed to be alive, was a really big challenge. In some situations we solved this with explicit disposal, but in other situations we *absolutely* needed Weak References to keep things sane, and going through and manually breaking cycles and removing event listeners and nulling parent references simply would not have been scalable. Even our best programmers wouldn't have been able to do it consistently. A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does - is really hard (for me, at least) to convey through design/comments and enforce manually with code. Having the aid of the type system and the runtime here is a huge boon. This is why the 'build your own malloc'/'build your own collector'/'do manual refcounting' solutions feel like a poor choice to me. Those solutions do a great job of solving resource management problems, because you can apply the cold unfeeling gaze of computer science to your software and eventually become confident that you will not have any resource management problems. The huge number of developers out there who intrinsically trust the garbage collector is great evidence of this. But when it comes to solving state/lifetime management problems, and being able to easily write code that you feel confident about in those contexts, solutions like manual refcounting or writing your own collector feel really inadequate. I've never come across a codebase that leaned upon solutions like that where you could feel true confidence; I've personally run into addref/release bugs in battle-tested codebases like Python and I've probably introduced my own more than a few times. I hope this makes it clearer why I want WeakRefs in particular, and perhaps it makes it easier to understand what an alternative solution might look like. Maybe the alternative solution is sugar for doing light-weight scoped addref/release, like Python's 'with' statement, or some other simple mechanism where people can at least confidently build their own solutions with the aid of the runtime, I'm not really sure. There are certainly vast millions of lines of C++ out there more or less leaning on such constructs, and those apps seem to work! On Tue, Apr 2, 2013 at 9:26 PM, Bill Frantz fra...@pwpconsult.com wrote: On 4/1/13 at 5:40 AM, sa...@ccs.neu.edu (Sam Tobin-Hochstadt) wrote: Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. There are a bunch of different reasons for wanting to dispose an object in memory. With the malloc/free system from C, you usually dispose objects to recover their backing memory for future use. The C version is not memory safe. If you are paying for the memory, you may be willing to break things to be able to stop
Re: Weak event listener
Le 27/03/2013 00:22, Kevin Gadd a écrit : OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. I've been through the thread and I haven't read any use case that *requires* Weak References. Only use cases where they make life easier to various degrees. It's been agreed that in most cases, adding an explicit .dispose() or equivalent protocol could work too. The only use case where I have some intuition of WeakRefs making a significant difference is the data binding use case. I find the compile weakrefs from another language use case a bit too early since compiling to JS is such a recent trend. As I said in one message, there is always a need of cutting some reference somewhere [1] for WeakRefs to work. What process needs to be followed before people will believe that Weak References are a real primitive that solves real problems? Do you need a set of broken, non-functional 'real world' applications written in JS that work in a customized version of V8/SpiderMonkey that has WRs? Do you need more verbose descriptions of use cases than previously provided? I can try to provide more justification than I did previously if this is necessary; I wasn't aware that it was. From what I read, until Jason joined the discussion, it was mostly me that was being annoying on use cases. So I can give my criteria if that helps (as a reminder, I'm not part of TC39, so you're also free to ignore what I say). I'd like to see the description of a use case (something more specific than just data binding) and an implementation that has been thought with memory management in mind. If this implementation proves to be minimalistic and simple enough, but yet too complex to use without WeakRefs, I'll be convinced. The thought with memory management in mind part is important. I don't think I have ever seen a talk describing a library where the author talked about the lifecycle of the objects created/used by the library. Memory footprint is sometimes discussed, but not lifecycle. From what I've observed, it's only after a severe memory leak is observed that people start to think about object lifecycle. Obviously, at that time, it's sometimes too late to do major refactoring and a lot of people would love to have weakrefs as a quickfix tool. From what I've observed too, very few people seem to understand GC at all. A lot of people still cite cycles as an issue of GC. So I wonder how many people really think of object lifecycles properly when designing libraries/frameworks. But what if object lifecycle was considered in the design? Maybe we'd realize WeakRefs are necessary to dramatically reduce the burden/boilerplate of some use cases. Maybe we'd find out a different way of designing libraries and realize WeakRefs aren't that necessary after all. Maybe tomorrow, i'll be writing a library and see the light or see the design of a library and see the light that without weakrefs, life is so much harder. I haven't yet come across such a case, so I'm not convinced yet. David [1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/028935.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mon, Apr 1, 2013 at 8:34 AM, David Bruant bruan...@gmail.com wrote: Le 27/03/2013 00:22, Kevin Gadd a écrit : OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. I've been through the thread and I haven't read any use case that *requires* Weak References. Only use cases where they make life easier to various degrees. It's been agreed that in most cases, adding an explicit .dispose() or equivalent protocol could work too. Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Right. David, I thought I had you convinced at: http://www.mail-archive.com/es-discuss@mozilla.org/msg21480.html /be Sam Tobin-Hochstadt wrote: On Mon, Apr 1, 2013 at 8:34 AM, David Bruantbruan...@gmail.com wrote: Le 27/03/2013 00:22, Kevin Gadd a écrit : OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. I've been through the thread and I haven't read any use case that *requires* Weak References. Only use cases where they make life easier to various degrees. It's been agreed that in most cases, adding an explicit .dispose() or equivalent protocol could work too. Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 27/03/2013 00:22, Allen Wirfs-Brock a écrit : On Mar 26, 2013, at 2:57 PM, David Bruant wrote: Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit : On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Set is also shimmable on top of Map. If Set is in, there are as many reason to have WeakSets in. If WeakSets are considered as second class, so should Set. I feel Set and WeakSet fate should be bound. It's really a consensus based judgement call based upon perceived breadth of utility. Both Map and WeakMap provide unique primitive functionality that is useful for creating other derived abstractions. Set can be implemented in terms of Map, but is expected to be used frequently enough that a consensus emerged for providing it as a built-in. WeakMap is used much less frequently than Map Not in my experience, but maybe I tend to keep using objects as maps as a biased reflex. Regardless, the balance may weigh in favor of WeakMap if private symbols are given up. but is needed because of its primitive GC behavior. If WeakSet will have even a smaller frequency of use than WeakMap and is easily expressed using WeakMap, then maybe it doesn't carry its own weight. A few usage cases may not be enough. Convince us that it's wide utility justifies, the specification, implementation, and testing overhead it adds. Fair enough. I'm not sure why you didn't just define yourself a WeakSet shim based upon a WeakMap Laziness to be fully honest :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Please read the memory safety and weak references thread. The issue is not just SES, which might remove an iterator in preparing the environment. Stock JS must not be vulnerable to jit-spray attacks due to enumerable weak maps. /be David Bruant wrote: I agree, but I don't see how it relates to what I wrote. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 3:05 PM, Brendan Eich bren...@mozilla.com wrote: Hi Jason, agree on your request for non-contrived use-cases. I wrote about the general observer pub/sub problem here: http://www.mail-archive.com/es-discuss@mozilla.org/msg21480.html Hope it helps. M. It does. What would work here is determinism: https://gist.github.com/jorendorff/5245857 It seems to me you want some kind of deterministic finalization or scoped destructor. That's not in the cards for JS. Oh -- no, my point was just that the API shown there can already be implemented just using 'finally'. I wasn't asking for any stronger guarantee than what 'finally' already provides. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 27/03/2013 15:52, Brendan Eich a écrit : Please read the memory safety and weak references thread. The issue is not just SES, which might remove an iterator in preparing the environment. Stock JS must not be vulnerable to jit-spray attacks due to enumerable weak maps. From what I understand of the attack, JS isn't vulnerable. Only current implementations are. I admit it carries some weight, but let's not confuse the 2. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
David Bruant wrote: Le 27/03/2013 15:52, Brendan Eich a écrit : Please read the memory safety and weak references thread. The issue is not just SES, which might remove an iterator in preparing the environment. Stock JS must not be vulnerable to jit-spray attacks due to enumerable weak maps. From what I understand of the attack, JS isn't vulnerable. Only current implementations are. I admit it carries some weight, but let's not confuse the 2. No, you are misreading again. JS if it has enumerable weakmaps (you advocate) plus real-world vulns in its impls (which are *inevitable*) makes pwnage. Changing the disagreement to be about JS vs. its impls is off the mark. Can you re-defend enumerability of weakmaps now that I've pointed out the security risk does not apply only to SES users, to be addressed by SES removing the @iterator? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mar 27, 2013 6:40 PM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Le 27/03/2013 15:52, Brendan Eich a écrit : Please read the memory safety and weak references thread. The issue is not just SES, which might remove an iterator in preparing the environment. Stock JS must not be vulnerable to jit-spray attacks due to enumerable weak maps. From what I understand of the attack, JS isn't vulnerable. Only current implementations are. I admit it carries some weight, but let's not confuse the 2. No, you are misreading again. JS if it has enumerable weakmaps (you advocate) plus real-world vulns in its impls (which are *inevitable*) makes pwnage. Changing the disagreement to be about JS vs. its impls is off the mark. Can you re-defend enumerability of weakmaps now that I've pointed out the security risk does not apply only to SES users, to be addressed by SES removing the @iterator? I don't think this is quite the right equation. What Dion's attack shows is that conservative stack scanning, when combined with any ability to observe GC, will leak some information about the addresses of objects. This can almost certainly be generalized to any conservative scanning. I also think that JS will inevitably need some method for GC-sensitive references, and this shows that combining these with conservative GC tech is risky. That may well be a reason to be more careful in the design of weak references, and to delay shipping them until engines improve. But I think the real lesson is that engines need to be on notice that conservative GC is a potential security risk, rather than a cost that the language has to bear forever. Fortunately, it seems that other incentives are already pushing engines toward precise GC. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Sam Tobin-Hochstadt wrote: Changing the disagreement to be about JS vs. its impls is off the mark. Can you re-defend enumerability of weakmaps now that I've pointed out the security risk does not apply only to SES users, to be addressed by SES removing the @iterator? I don't think this is quite the right equation. I didn't mean to equate anything, but the issue in this thread that I was getting back to was observable lifetimes through weak map enumeration. What Dion's attack shows is that conservative stack scanning, when combined with any ability to observe GC, will leak some information about the addresses of objects. This can almost certainly be generalized to any conservative scanning. Agreed. I also think that JS will inevitably need some method for GC-sensitive references, and this shows that combining these with conservative GC tech is risky. That may well be a reason to be more careful in the design of weak references, and to delay shipping them until engines improve. But I think the real lesson is that engines need to be on notice that conservative GC is a potential security risk, rather than a cost that the language has to bear forever. Fortunately, it seems that other incentives are already pushing engines toward precise GC. It's true that conservative scanning is on the outs, sometimes as a matter of principle (David Ungar one remarked to me that he did not consider conservative GC to be real GC). But engines do it and ECMA-262 does not rule it out. What makes conservative scanning troublesome, in the present case, is the design of weak maps as implemented in Tamarin (AS3 was the target Dion exploited). My conclusion is different from yours, which I suggest is unfairly biased against conservative GC :-). I say we need careful weak ref notification (end-of-turn with an empty stack may be sufficient), and *no* enumeration of weakmaps. And that last conjunct is what David was disputing. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Wed, Mar 27, 2013 at 9:09 PM, Brendan Eich bren...@mozilla.com wrote: What Dion's attack shows is that conservative stack scanning, when combined with any ability to observe GC, will leak some information about the addresses of objects. This can almost certainly be generalized to any conservative scanning. Agreed. I also think that JS will inevitably need some method for GC-sensitive references, and this shows that combining these with conservative GC tech is risky. That may well be a reason to be more careful in the design of weak references, and to delay shipping them until engines improve. But I think the real lesson is that engines need to be on notice that conservative GC is a potential security risk, rather than a cost that the language has to bear forever. Fortunately, it seems that other incentives are already pushing engines toward precise GC. It's true that conservative scanning is on the outs, sometimes as a matter of principle (David Ungar one remarked to me that he did not consider conservative GC to be real GC). But engines do it and ECMA-262 does not rule it out. I agree with all of that (including Ungar's opinion :). ECMA-262 doesn't rule out other security-risky implementation choices either [1]. What makes conservative scanning troublesome, in the present case, is the design of weak maps as implemented in Tamarin (AS3 was the target Dion exploited). My conclusion is different from yours, which I suggest is unfairly biased against conservative GC :-). I say we need careful weak ref notification (end-of-turn with an empty stack may be sufficient), and *no* enumeration of weakmaps. And that last conjunct is what David was disputing. I agree we need to be careful, and I don't think we should add weak map enumeration right now. However, I think this demonstration makes a much stronger case against conservative GC. Dion's attack requires, fundamentally, three things: 1. Conservative GC (of any form). 2. Some data structure that the browser holds weakly if at all, but can be held strongly from JS. 3. Some way to tell if that data is collected. I think that there's no way to eliminate 2 3 from the browser. For example, 2 could be a large array, and 3 could be a `currentMemoryUse` function (which doesn't currently exist, but might). Or, 2 could be image data (which browsers may discard when you scroll away, but not if JS has a reference to the DOM node in question) and 3 could be a site that detects HTTP re-requests for those images and communicates with the attacking script by XHR. Or 2 could be any data structure that the browser memoizes creation of observably, and 3 is === on a new allocation of that structure. Now, each of these particular issues could be mitigated. And probably some of them (like the image one) are way too slow to be practical for a full address leak. But, (a) just leaking some data helps defeat techniques like ASLR, (b) learning heap locations is bad, although perhaps not as bad as stack locations, and (c) browsers are a huge surface area to eliminate this behavior from. This stuff is almost certainly not the low-hanging fruit that we'll see in the next Pwn2Own, but it's going to be next to impossible to eliminate entirely without precise collection. Sam [1] C++, for example. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Sam Tobin-Hochstadt wrote: However, I think this demonstration makes a much stronger case against conservative GC. Dion's attack requires, fundamentally, three things: 1. Conservative GC (of any form). 2. Some data structure that the browser holds weakly if at all, but can be held strongly from JS. 3. Some way to tell if that data is collected. I think that there's no way to eliminate 2 3 from the browser. For example, 2 could be a large array, and 3 could be a `currentMemoryUse` function (which doesn't currently exist, but might). Such a currentMemoryUse function would not be easy to standardize, just on interop and complexity of implementation grounds, if not on the liveness channel attack. But you are right in general: Dion tried a weakmap timing channel attack, since SpiderMonkey's WeakMap is based on doubling a HashMap when it fills to a certain load factor. However, he couldn't get that attack to work. These channels may be noisy. The problem with weak refs with prompt notification, or enumerable weakmap, is that those leak much more precise liveness info. Security is always like this, a set of cross-cutting (non-modular) properties -- safety properties in Fred Schneider's formulation (predicates over all future program states). So I don't see how we can look at conservative GC with an evil eye but not look at other parts of the system. Let's say we ban conservative GC as part of ECMA-262's normative language. We still have interop and capability or authority problems with enumerable weakmaps. Those are not concerns only for SES. I agree conservative GC makes the system more vulnerable, since (2) happens (even if under the hood, but in ES6 code above the hood), and (3) is an endless stream of weaknesses and hard-to-close channels. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
So to summarize: - This would be very useful in large MVC applications with many independent components. - Even with WeakMaps there is no way to implement weak event listeners, since WeakMaps cannot be iterated. A weak reference implementation would solve this. - The main problem with weak event listeners is that they are not deterministic; even if you remove all references to an object there is no way to ensure that the object is garbage collected immediately, and so events would still be dispatched to it for an indeterminable period of time after the last strong reference is severed. I'm not sure of how big of a problem this would be; it might be an annoyance or it might break the application completely. Marius Gundersen On Tue, Mar 26, 2013 at 4:24 AM, Benoit Marchant march...@mac.com wrote: Very true, I'm wondering if based on usage today it could make sense to have this as default behavior on current API? Benoit On Mar 25, 2013, at 19:51, Peter Michaux petermich...@gmail.com wrote: On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote: One thing which is impossible to make in JavaScript today is a weakly referenced event listener system. In such a system an event listener is not strongly referenced by the event system, so events are only dispatched to it as long as another object holds a reference to it. Being able to make an observable subject that keeps a weak list of observers would be very useful to ease memory management within an application and avoid accidental memory leaks at the application level. Sometimes the application programmer may forgot to remove a observer from an observable subject, for example. With regard to the MVC architecture, this could be the best addition to the language to make application development easier. A view might mistakenly not unsubscribe from its associate model when the view is destroyed, for example. That or the view's destroy method is never even called because the application programmer forgot to call it. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
2013/3/25 Erik Arvidsson erik.arvids...@gmail.com WeakMap would not work in this specific case since a WeakMap cannot be iteratered. I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or just dropped? Thanks, Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
2013/3/26 Juan Ignacio Dopazo dopazo.j...@gmail.com 2013/3/25 Erik Arvidsson erik.arvids...@gmail.com WeakMap would not work in this specific case since a WeakMap cannot be iteratered. I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or just dropped? I doubt there was ever an *iterable* WeakSet proposal, since iteration would make GC of the weakly held values observable. This is exactly the same reason why WeakMap isn't iterable. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 9:46 AM, Tom Van Cutsem tomvc...@gmail.com wrote: 2013/3/26 Juan Ignacio Dopazo dopazo.j...@gmail.com 2013/3/25 Erik Arvidsson erik.arvids...@gmail.com WeakMap would not work in this specific case since a WeakMap cannot be iteratered. I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or just dropped? I doubt there was ever an *iterable* WeakSet proposal, since iteration would make GC of the weakly held values observable. This is exactly the same reason why WeakMap isn't iterable. Cheers, Tom TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Mark Miller proposed semantics for WeakRefs to satisfy security concerns: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html Both of these should be discussed at the next meeting. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Weak event listener
From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. Mark Miller proposed semantics for WeakRefs to satisfy security concerns: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html I assume this is ES7 timeframe, even if it'll be discussed at the next meeting? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Mark Miller proposed semantics for WeakRefs to satisfy security concerns: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html I assume this is ES7 timeframe, even if it'll be discussed at the next meeting? I don't know the answer to this question, sorry. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Note that this requirement is conditional on a particular approach (which I still favor) to the interaction between proxies and private names, and so since that's still up in the air, the WeakSet requirement for ES6 may go away. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. WeakRef will definitely not happen earlier than ES7. I do hope it will happen in ES7, but this discussion has yet to happen. On Tue, Mar 26, 2013 at 4:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Note that this requirement is conditional on a particular approach (which I still favor) to the interaction between proxies and private names, and so since that's still up in the air, the WeakSet requirement for ES6 may go away. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: WeakMap would not work in this specific case since a WeakMap cannot be iteratered. What would work here is determinism: https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. The main justification I’ve heard for WeakRef is that sometimes it’s hard to unhook observers at the point where you find you don't want them anymore. That’s plausible. I'd really appreciate some better examples of how this comes up and (especially) how WeakRef helps in practice. The References section of the strawman is just a collection of links to reactive libraries like Tangle[1], without elaboration. But if Tangle actually used weak observer semantics, even the most basic Tangle use cases would break! [2] I don't mean to pick on WeakRef. Across the board, I would love to see better motivating use cases for all proposals: less contrived, and actually illustrating the benefit of the proposal. I don’t think it’s too much to ask. The modules proposal has suddenly gone from one of the worst-motivated proposals in ES6 to perhaps the best, with scads of excellent use cases. More of that, please! -j [1]http://worrydream.com/Tangle/ [2]http://worrydream.com/Tangle/Examples/CookieExample.js Note that after the observer is hooked up, it immediately becomes unreachable (except via Tangle itself) as soon as that function returns. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Hi Jason, agree on your request for non-contrived use-cases. I wrote about the general observer pub/sub problem here: http://www.mail-archive.com/es-discuss@mozilla.org/msg21480.html Hope it helps. One specific thought below. Jason Orendorff wrote: What would work here is determinism: https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. It seems to me you want some kind of deterministic finalization or scoped destructor. That's not in the cards for JS. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Which is why it isn't the in the spec. yet. It was introduced in support of Proxy private Symbol white list, but it is still unclear whether we will have them and even if we do, it's not clear that the actual internal whitelist needs to be exposed as a WeakSet. WeakRef will definitely not happen earlier than ES7. I do hope it will happen in ES7, but this discussion has yet to happen. On Tue, Mar 26, 2013 at 4:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Mar 26, 2013 at 12:28 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:23 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] TC39 reached consensus on the inclusion of WeakSet, though it needs to be designed: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset Is this ES6 timeframe, or ES7? I have run into a few use cases for it since hearing this, and was hoping it was on-track. The discussion immediately preceding that discussion indicates that WeakSet will be a requirement of Proxy: https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#proxy-and-private-names Note that this requirement is conditional on a particular approach (which I still favor) to the interaction between proxies and private names, and so since that's still up in the air, the WeakSet requirement for ES6 may go away. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On 3/26/2013 1:03 PM, David Bruant wrote: I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? This is a question I had as well. An iterable WeakMap is nearly the same as a Map full of WeakRefs, is it not? Just a different API that is less usable for single references and more usable for collections. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 26/03/2013 21:26, Brandon Benvie a écrit : On 3/26/2013 1:03 PM, David Bruant wrote: I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? This is a question I had as well. An iterable WeakMap is nearly the same as a Map full of WeakRefs, is it not? Just a different API that is less usable for single references and more usable for collections. Interestingly, publish-subscribe would probably make a better use of an iterable weakset (set of observers) I think: When a publication happens, what needs to be done is tell all the (remaning) subscribers. I don't think anyone really needs the weakrefs themselves. Iterating over remaining observers seems to be enough. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit : On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Set is also shimmable on top of Map. If Set is in, there are as many reason to have WeakSets in. If WeakSets are considered as second class, so should Set. I feel Set and WeakSet fate should be bound. Which is why it isn't the in the spec. yet. It was introduced in support of Proxy private Symbol white list, but it is still unclear whether we will have them and even if we do, it's not clear that the actual internal whitelist needs to be exposed as a WeakSet. I don't understand the reluctance towards having WeakSets in spec. They have as much use as WeakMaps. Domenic wrote a couple of messages ago I have run into a few use cases for [WeakSet] (...), and was hoping it was on-track. I've had a case too and even left a comment about it [1]. We can argue whether, that's a use case more for private symbols than WeakSet, but still, weaksets sounds like an appriopriate tool for appropriate situations. David [1] https://github.com/DavidBruant/HarmonyProxyLab/blob/413a153c01b34bfc281b901b399ac09f3ca8c0d7/ES3AndProxy/ES5ObjectModelEmul.js#L57 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Le 26/03/2013 22:56, Mark S. Miller a écrit : Because the weak-map-maker constructor grants no privilege and can be generally accessible, whereas the weak-ref-maker grants the privilege of being able to observe the non-determinism of GC, and so should not be made accessible to code that shouldn't have such powers. It is the same reason why Maps and Sets, which are enumerable, enumerate their elements in a deterministic order. In short, separation of concerns as well as separation of privileges. If WeakMaps were granted the privilege of observing GC non-determinism via iteration, I assume it would be through a default WeakMap.prototype.@@iterator (that's how it works for Map). Removing this authority can be done by providing another WeakMap constructor with 'null' as WeakMap.prototype.@@iterator which is pretty much as much work as removing access to the weak-ref-maker. Thanks to the iterator protocol (and especially the @@iterator symbol), privileges can be kept separate, so I don't think it's a sufficient enough reason to not allow iteration over WeakMaps if WeakRefs are in. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Tue, Mar 26, 2013 at 10:14 PM, David Bruant bruan...@gmail.com wrote: Le 26/03/2013 22:56, Mark S. Miller a écrit : Because the weak-map-maker constructor grants no privilege and can be generally accessible, whereas the weak-ref-maker grants the privilege of being able to observe the non-determinism of GC, and so should not be made accessible to code that shouldn't have such powers. It is the same reason why Maps and Sets, which are enumerable, enumerate their elements in a deterministic order. In short, separation of concerns as well as separation of privileges. If WeakMaps were granted the privilege of observing GC non-determinism via iteration, I assume it would be through a default WeakMap.prototype.@@iterator (that's how it works for Map). Removing this authority can be done by providing another WeakMap constructor with 'null' as WeakMap.prototype.@@iterator which is pretty much as much work as removing access to the weak-ref-maker. Thanks to the iterator protocol (and especially the @@iterator symbol), privileges can be kept separate, so I don't think it's a sufficient enough reason to not allow iteration over WeakMaps if WeakRefs are in. WeakRefs are *not* in ES6, because getting these privilege separation issues right is hard, and is best done after real experience using the new module system. David __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mar 26, 2013, at 2:57 PM, David Bruant wrote: Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit : On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote: WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet is trivially shimmable on WeakMap. Set is also shimmable on top of Map. If Set is in, there are as many reason to have WeakSets in. If WeakSets are considered as second class, so should Set. I feel Set and WeakSet fate should be bound. It's really a consensus based judgement call based upon perceived breadth of utility. Both Map and WeakMap provide unique primitive functionality that is useful for creating other derived abstractions. Set can be implemented in terms of Map, but is expected to be used frequently enough that a consensus emerged for providing it as a built-in. WeakMap is used much less frequently than Map but is needed because of its primitive GC behavior. If WeakSet will have even a smaller frequency of use than WeakMap and is easily expressed using WeakMap, then maybe it doesn't carry its own weight. A few usage cases may not be enough. Convince us that it's wide utility justifies, the specification, implementation, and testing overhead it adds. Which is why it isn't the in the spec. yet. It was introduced in support of Proxy private Symbol white list, but it is still unclear whether we will have them and even if we do, it's not clear that the actual internal whitelist needs to be exposed as a WeakSet. I don't understand the reluctance towards having WeakSets in spec. They have as much use as WeakMaps. Domenic wrote a couple of messages ago I have run into a few use cases for [WeakSet] (...), and was hoping it was on-track. I've had a case too and even left a comment about it [1]. We can argue whether, that's a use case more for private symbols than WeakSet, but still, weaksets sounds like an appriopriate tool for appropriate situations. David [1] https://github.com/DavidBruant/HarmonyProxyLab/blob/413a153c01b34bfc281b901b399ac09f3ca8c0d7/ES3AndProxy/ES5ObjectModelEmul.js#L57 I'm not sure why you didn't just define yourself a WeakSet shim based upon a WeakMap ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. What process needs to be followed before people will believe that Weak References are a real primitive that solves real problems? Do you need a set of broken, non-functional 'real world' applications written in JS that work in a customized version of V8/SpiderMonkey that has WRs? Do you need more verbose descriptions of use cases than previously provided? I can try to provide more justification than I did previously if this is necessary; I wasn't aware that it was. I totally understand that security concerns and the limited number of hours in the day have caused WRs to be postponed until ES7 or later (though this makes me annoyed for obvious reasons), but if WRs as a useful feature are somehow in such question that people are suggesting they are unnecessary, I want to know how they got into this position and how to fix it. The question of whether the non-determinism is justified is a hard one, of course. Right now applications that need WRs aren't JS applications, so WRs only pull their weight if it is worthwhile to have those applications brought into the browser (instead of remaining in native execution environments like NaCL or being emulated by a custom garbage collector implementation inside of emscripten with typed arrays acting as a virtual heap). I can't answer the question of whether iterable WeakMaps are equivalent to weak references. I do believe that with iterable WeakMaps you could determine whether a given object has been collected, but I am having a hard time imagining how one could performantly implement a Weak Reference via an iterable WeakMap. The most obvious implementation would be to create a single-key WeakMap for every Weak Reference, and treating the reference as dead when the map contains 0 items. This would certainly 'work', but seems like a rather roundabout way of solving the problem. With an iterable WeakSet you'd at least be reducing the overhead, so that might be alright. If this roundabout solution could get into ES6, then I suppose I would probably prefer it to real WRs in ESsome larger digit, because I prefer solving customers' problems now to solving the problems of future customers later. Thanks, -kg On Tue, Mar 26, 2013 at 1:03 PM, David Bruant bruan...@gmail.com wrote: Le 26/03/2013 20:25, Jason Orendorff a écrit : On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: WeakMap would not work in this specific case since a WeakMap cannot be iteratered. What would work here is determinism: https://gist.github.com/**jorendorff/5245857https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. I'm not entirely sure I understand your code snippet. Is withListener some equivalent of Node's once [1][2]? If so, then I agree, but, we're back to a debate earlier this month starting at [3] (implicitly forked). From the previous discussions, my understanding of the problem that weakrefs are expected to solve is automated cascading of GC, that is, a full subgraph gets collected as a result of releasing one reference assuming the convention that everyone with access to the weakref plays nice by always accessing the object via .get, and I guess via releasing the weakref (which is itself an object?) when useless. I'm still not entirely convinced whether the problem being solved is worth the non-determinism it brings along. I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? The References section of the strawman is just a collection of links to reactive libraries like Tangle[1], without elaboration. But if Tangle actually used weak observer semantics, even the most basic Tangle use cases would break! [2] The precedent of other languages was used as a justification of doing the same in JS and I guess this example is a good case of why this might not be a good argument. In JS, listeners are functions which are their own objects and keeping one hard reference imposes a different constraint than in other languages. David [1] http://nodejs.org/api/events.**html#events_emitter_once_** event_listenerhttp://nodejs.org/api/events.html#events_emitter_once_event_listener [2] https://github.com/joyent/**node/blob/**2eb847849fc133e39d64798bee0125
Re: Weak event listener
On Tue, Mar 26, 2013 at 11:22 PM, Kevin Gadd kevin.g...@gmail.com wrote: OK, it seems like Weak References are now being discussed without the context of previous discussions of weak references, which is a little annoying. Non-contrived real-world use cases that require Weak References (or a primitive with similar capabilities, like a Map with weak values instead of weak keys, I'm not picky) have already been provided *on this list* the last time WRs were discussed. I provided two based on real applications I've worked on; I thought other people in the discussion thread provided more. What process needs to be followed before people will believe that Weak References are a real primitive that solves real problems? Do you need a set of broken, non-functional 'real world' applications written in JS that work in a customized version of V8/SpiderMonkey that has WRs? Do you need more verbose descriptions of use cases than previously provided? I can try to provide more justification than I did previously if this is necessary; I wasn't aware that it was. I totally understand that security concerns and the limited number of hours in the day have caused WRs to be postponed until ES7 or later (though this makes me annoyed for obvious reasons), but if WRs as a useful feature are somehow in such question that people are suggesting they are unnecessary, I want to know how they got into this position and how to fix it. The question of whether the non-determinism is justified is a hard one, of course. Right now applications that need WRs aren't JS applications, so WRs only pull their weight if it is worthwhile to have those applications brought into the browser (instead of remaining in native execution environments like NaCL or being emulated by a custom garbage collector implementation inside of emscripten with typed arrays acting as a virtual heap). I can't answer the question of whether iterable WeakMaps are equivalent to weak references. I do believe that with iterable WeakMaps you could determine whether a given object has been collected, but I am having a hard time imagining how one could performantly implement a Weak Reference via an iterable WeakMap. The most obvious implementation would be to create a single-key WeakMap for every Weak Reference, and treating the reference as dead when the map contains 0 items. This would certainly 'work', but seems like a rather roundabout way of solving the problem. With an iterable WeakSet you'd at least be reducing the overhead, so that might be alright. If this roundabout solution could get into ES6, It can't, because it raises all the hard issues raised by weak-refs. We are not going to add issues this deep to ES6 at this date. We've already postponed easier issues to ES7. then I suppose I would probably prefer it to real WRs in ESsome larger digit, because I prefer solving customers' problems now to solving the problems of future customers later. Thanks, -kg On Tue, Mar 26, 2013 at 1:03 PM, David Bruant bruan...@gmail.com wrote: Le 26/03/2013 20:25, Jason Orendorff a écrit : On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: WeakMap would not work in this specific case since a WeakMap cannot be iteratered. What would work here is determinism: https://gist.github.com/**jorendorff/5245857https://gist.github.com/jorendorff/5245857 For this, a deterministic API is just as easy to use, easier to implement, and easier to reason about. I'm not entirely sure I understand your code snippet. Is withListener some equivalent of Node's once [1][2]? If so, then I agree, but, we're back to a debate earlier this month starting at [3] (implicitly forked). From the previous discussions, my understanding of the problem that weakrefs are expected to solve is automated cascading of GC, that is, a full subgraph gets collected as a result of releasing one reference assuming the convention that everyone with access to the weakref plays nice by always accessing the object via .get, and I guess via releasing the weakref (which is itself an object?) when useless. I'm still not entirely convinced whether the problem being solved is worth the non-determinism it brings along. I'm starting to wonder whether bringing weakrefs is equivalent to having iterable WeakMaps... And if so, why not make WeakMaps iterable? The References section of the strawman is just a collection of links to reactive libraries like Tangle[1], without elaboration. But if Tangle actually used weak observer semantics, even the most basic Tangle use cases would break! [2] The precedent of other languages was used as a justification of doing the same in JS and I guess this example is a good case of why this might not be a good argument. In JS, listeners are functions which are their own objects and keeping one hard reference imposes a different constraint than in other languages. David [1]
Weak event listener
I tried posting this before, but it seems to have gotten lost on the
internet.
One thing which is impossible to make in JavaScript today is a weakly
referenced event listener system. In such a system an event listener is not
strongly referenced by the event system, so events are only dispatched to
it as long as another object holds a reference to it. For example:
//some weak event system, could be global or created with constructor
var events = new WeakEventSystem();
(function(){
//This object only exists inside this IIFE, not outside it
var myObject = {
handler: function(event){
console.log(handle event: + event);
}
};
//add a listener to events, but events only has a weak reference to it
events.addEventListener(someEvent, myObject.handler);
//the following causes the handler above to be called, resulting in
output on the console
events.dispatchEvent(someEvent, {params:someParams});
})();
//myObject does not exist anymore
//the following does not output anything on the console
events.dispatchEvent(someEvent, {params:someParams});
In this example the event system does not hold a strong reference to the
listener/handler function, so if nothing else has a reference to the
handler function, it is garbage collected.
Any thoughts on this, as an alternative to the more general (and low level)
weak references?
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Most use cases I've personally seen for weak events would be satisfied by a
WeakMap of weak event target - event handler. Having the event handler
itself be weak instead of the event target seems strange to me; it
introduces a bunch of nondeterministic behavior that isn't desirable -
sometimes you'll free all your references to a handler and it'll fire
anyway, because it hasn't been collected. It also introduces the potential
for accidentally freeing all your references to a handler and having
important behavior not run. If you get proper WRs this should be pretty
easy to build if you want it.
I think the fact that this would make GC behavior observable through the
execution/non-execution of event handlers probably makes it some sort of
security hole in the same way that WRs are, but I'm not sure - I've never
fully understood the threat posed by that information leak.
-kg
On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.comwrote:
I tried posting this before, but it seems to have gotten lost on the
internet.
One thing which is impossible to make in JavaScript today is a weakly
referenced event listener system. In such a system an event listener is not
strongly referenced by the event system, so events are only dispatched to
it as long as another object holds a reference to it. For example:
//some weak event system, could be global or created with constructor
var events = new WeakEventSystem();
(function(){
//This object only exists inside this IIFE, not outside it
var myObject = {
handler: function(event){
console.log(handle event: + event);
}
};
//add a listener to events, but events only has a weak reference to it
events.addEventListener(someEvent, myObject.handler);
//the following causes the handler above to be called, resulting in
output on the console
events.dispatchEvent(someEvent, {params:someParams});
})();
//myObject does not exist anymore
//the following does not output anything on the console
events.dispatchEvent(someEvent, {params:someParams});
In this example the event system does not hold a strong reference to the
listener/handler function, so if nothing else has a reference to the
handler function, it is garbage collected.
Any thoughts on this, as an alternative to the more general (and low
level) weak references?
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-kg
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
WeakMap would not work in this specific case since a WeakMap cannot be
iteratered.
WeakRefs are needed to do data binding and pub sub systems like these.
WeakRefs are very likely to be part of ES7. We haven't really talked much
about them formally but informally TC39 members seems to agree.
http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs
On Mon, Mar 25, 2013 at 9:28 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Most use cases I've personally seen for weak events would be satisfied by
a WeakMap of weak event target - event handler. Having the event handler
itself be weak instead of the event target seems strange to me; it
introduces a bunch of nondeterministic behavior that isn't desirable -
sometimes you'll free all your references to a handler and it'll fire
anyway, because it hasn't been collected. It also introduces the potential
for accidentally freeing all your references to a handler and having
important behavior not run. If you get proper WRs this should be pretty
easy to build if you want it.
I think the fact that this would make GC behavior observable through the
execution/non-execution of event handlers probably makes it some sort of
security hole in the same way that WRs are, but I'm not sure - I've never
fully understood the threat posed by that information leak.
-kg
On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.comwrote:
I tried posting this before, but it seems to have gotten lost on the
internet.
One thing which is impossible to make in JavaScript today is a weakly
referenced event listener system. In such a system an event listener is not
strongly referenced by the event system, so events are only dispatched to
it as long as another object holds a reference to it. For example:
//some weak event system, could be global or created with constructor
var events = new WeakEventSystem();
(function(){
//This object only exists inside this IIFE, not outside it
var myObject = {
handler: function(event){
console.log(handle event: + event);
}
};
//add a listener to events, but events only has a weak reference to it
events.addEventListener(someEvent, myObject.handler);
//the following causes the handler above to be called, resulting in
output on the console
events.dispatchEvent(someEvent, {params:someParams});
})();
//myObject does not exist anymore
//the following does not output anything on the console
events.dispatchEvent(someEvent, {params:someParams});
In this example the event system does not hold a strong reference to the
listener/handler function, so if nothing else has a reference to the
handler function, it is garbage collected.
Any thoughts on this, as an alternative to the more general (and low
level) weak references?
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
-kg
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote: One thing which is impossible to make in JavaScript today is a weakly referenced event listener system. In such a system an event listener is not strongly referenced by the event system, so events are only dispatched to it as long as another object holds a reference to it. Being able to make an observable subject that keeps a weak list of observers would be very useful to ease memory management within an application and avoid accidental memory leaks at the application level. Sometimes the application programmer may forgot to remove a observer from an observable subject, for example. With regard to the MVC architecture, this could be the best addition to the language to make application development easier. A view might mistakenly not unsubscribe from its associate model when the view is destroyed, for example. That or the view's destroy method is never even called because the application programmer forgot to call it. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
Very true, I'm wondering if based on usage today it could make sense to have this as default behavior on current API? Benoit On Mar 25, 2013, at 19:51, Peter Michaux petermich...@gmail.com wrote: On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote: One thing which is impossible to make in JavaScript today is a weakly referenced event listener system. In such a system an event listener is not strongly referenced by the event system, so events are only dispatched to it as long as another object holds a reference to it. Being able to make an observable subject that keeps a weak list of observers would be very useful to ease memory management within an application and avoid accidental memory leaks at the application level. Sometimes the application programmer may forgot to remove a observer from an observable subject, for example. With regard to the MVC architecture, this could be the best addition to the language to make application development easier. A view might mistakenly not unsubscribe from its associate model when the view is destroyed, for example. That or the view's destroy method is never even called because the application programmer forgot to call it. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
