Promise based Observable proposal

Hi everyone, I've been working on implementing a Promise based Observable proposal. The main goal is to make the Observable composable, every subscribe will return a new Observable, and every listener will try to resolve the returned value as a Promise. Promise can't resolve multiple times, this

Re: Is `undefined` garabage collectable?

The `undefined` value is represented in exactly the same way as `true`, `false`, and `null` in V8. They're so called "oddballs" internally, global values that are neither allocated nor freed. Either way, the key/values of a (regular) map do not keep anything alive about the map. Adding or

Better way to maintain this reference on event listener functions

Sorry if I've missed any previous requests for this feature, but is there any goal to allow callbacks passed to event listeners to keep their `this` context without having to store a reference to the this-binded event listener first? I frequently find myself doing this in my class methods:

Re: Better way to maintain this reference on event listener functions

This is rather about DOM land, nothing to do with EcmaScript standard. I'll quickly answer but please bear in mind this mailing list is about ES, not about WHATWG or W3C, thanks. Since DOM Level 3 has been available (every browser compatible with addEventListener, polyfilled for IE8 too if

Subject=Re: Re: Better way to maintain this reference on event listener functions

Wow that's so ironic because [I posted this same idea]( https://github.com/whatwg/dom/issues/245#issuecomment-217816301) (literally copied and pasted) in WHATWG's "DOM land" and they told me this was an es-discuss issue. So which is it? Oh and thanks for the code sample but it uses the old

Re: Re: Better way to maintain this reference on event listener functions

Wow that's so ironic because [I posted this same idea]( https://github.com/whatwg/dom/issues/245#issuecomment-217816301) (literally copied and pasted) in WHATWG's "DOM land" and they told me this was an es-discuss issue. So which is it? Oh and thanks for the code sample but it uses the old

Re: Subject=Re: Re: Better way to maintain this reference on event listener functions

Raising a concern about `addEventListener` and its context probably made me think it was rather a WHATWG concern. Anyway, I don't know why you had to point out the `class` keyword ... I mean ```js class SomeClass { constructor(someNode) { someNode.addEventListener('click', this); },

Re: Re: Better way to maintain this reference on event listener functions

Raising a concern about `addEventListener` and its context probably made me think it was rather a WHATWG concern. Anyway, I don't know why you had to point out the `class` keyword ... I mean ```js class SomeClass { constructor(someNode) { someNode.addEventListener('click', this); },

Re: Re: Better way to maintain this reference on event listener functions

uhm, I've used commas ... anyway, the sugar is desugaring to old methods, this is working example: ```js class SomeClass { constructor(someNode) { someNode.addEventListener('click', this); } onclick(e) { alert(this.constructor.name); // SomeClass } handleEvent(e) { this['on'

RE: Subject=Re: Re: Better way to maintain this reference on event listener functions

To give some clarity to "whose concern is it", the idea of it being an ES concern is that this is a concern for all APIs that accept a callback. addEventListener is a simple example. I think ES has already given an answer to this question: `Function.prototype.bind`. I'm not sure what the OP

Re: Re: Better way to maintain this reference on event listener functions

Hi Mark, not sure I understand. What you are doing is exactly the same, there is no difference whatsoever with what I've shown to you. > Yes but what happens when you have multiple event targets using the same `type` of event? You're going to require a lot of extra conditionals in `onclick`

Re: Re: Better way to maintain this reference on event listener functions

Sorry maybe I'm not explaining this the right way. My original intent is to lessen the code that I would have to write to achieve multiple event handlers which do different things on multiple DOM elements when constructing a class and also REMOVING the event listeners manually. I am assuming this

Re: Better way to maintain this reference on event listener functions

On 5/9/16 12:37 PM, Mark Kennedy wrote: and also REMOVING the event listeners manually. I think this is the key part. What is the precise use case for removing here? I think that affects how this would best be designed. The obvious case is when you want to remove the listener at the point

Re: Better way to maintain this reference on event listener functions

Oh well, if removing after first click is the use-case, `el.addEventListener('click', this.onClick, {once: true})` is already in the standard pipeline (and polyfilled in dom4) Best Regards On Mon, May 9, 2016 at 5:41 PM, Boris Zbarsky wrote: > On 5/9/16 12:37 PM, Mark Kennedy

Re: Re: Better way to maintain this reference on event listener functions

Haha, no problem, Andrea. I think I may have not explained the scenario as clearly in my original post so I apologize for that. But like Boris mentioned, removing the event listeners in a much easier way is also a part of my goal here. I do like passing context in an argument and if using the

Re: Better way to maintain this reference on event listener functions

I'm confused by this whole thread. There is nothing here that cannot be handled easily by a minimal amount of user glue code, to give just one example: ```js function listen(element, type, handler) { element.addEventListener(type, handler); return function() {

Re: Better way to maintain this reference on event listener functions

Thanks, Bob. Unless I'm missing something, this code you wrote will not remove the event listener when `unlisten` is called. Check out [this answer](http://stackoverflow.com/a/30448329/2810742) on stackoverflow. ```js function listen(element, type, handler) { element.addEventListener(type,

Re: Better way to maintain this reference on event listener functions

Yes, you are missing something. This code will absolutely remove it the handler, because the handler being passed to both `addEventListener` and `removeEventListener is identical (in the `===` sense). On Mon, May 9, 2016 at 10:50 PM, Mark Kennedy wrote: > Thanks, Bob. Unless

Re: Better way to maintain this reference on event listener functions

Oh yeah my apologies, handler is a variable that gets passed to removeEventListener when invoked. -- mark Sent while riding a hoverboard... heyimmark.com :) ___ es-discuss mailing list es-discuss@mozilla.org

Re: Better way to maintain this reference on event listener functions

I do still feel your examples are still storing a reference to the intended handler function and having this sort of glue is unnecessary to have to write for every class that is created. It would be nice if this would handled by the language automatically.

Re: Is `undefined` garabage collectable?

Thanks Andreas, that's helpful to know. In general, is there some way to keep a list (adding removing things over time) while avoiding GC? For example, I thought I could place and remove items into a list (f.e. Set or Map, while having my own references to all the items and the list and outside

Re: Better way to maintain this reference on event listener functions

You don't need to rewrite such utilities for every class by any means. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promise based Observable proposal

Probably best to first see how people react here: https://github.com/zenparsing/es-observable You also might appreciate the async generator/iterator proposal here: https://github.com/tc39/proposal-async-iteration (Note: observables push directly to iterators and are event based, while async

Re: Is `undefined` garabage collectable?

I'll just point this out: low level optimization like that is very unintuitive. Game engines often use object pools to avoid allocation and GC, since even a single `malloc` is sometimes too expensive. There's other ways of reducing GC as well, such as persistence (like persistent data structures

Proposing a conditional assignment (or equals) operator

I see this has been discussed on this list a number of times before -- I found this thread , and reviewed the linked discussions and previous strawmen (I hope that link is enough to establish context and why the operator is

Re: operator overloading proposal

> And remember that decorators are essentially just a syntax to apply functions to objects/classes at design time, so what you're proposing is essentially some new global function, which is going against the current trend and effort to better modularize/namespace all these utility