AFAIK bluebird did:
https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise
But I agree once you've made Promises more complex than events ( xhr in
this case ) nobody wins :-/
Although, specially for fetch or anything network related, there **must**
be a way to
another basic example with listeners
```
window.addEventListener('load', (e) = {
// how am I going to remove this listener?
console.log('everything loaded');
});
```
Specially on UI world, many libraries do attach tons of things at runtime,
within methods, and have no way to remove them if
The discussion on that github issue surrounding promise subclassing makes
my head spin, especially when it comes to working out how cancelation is
supposed to flow through a graph of promise dependencies. We should be
wary of adding complexity to the core.
The simple way to view the situation is
Am I the only one who finds it weird to use `function.something` inside a
function?
```
function doSomething () {
function.self...
}
```
That's why I was thinking in something more related to the scope than to
the function object itself.
On Thu, Feb 26, 2015 at 11:32 PM, Matthew Robb
As a heads up, there's some debate around the fetch() API how exactly
request termination should work and how that affects promises:
https://github.com/slightlyoff/ServiceWorker/issues/625
The WebRTC WG has also been discussing canceling in the context of
terminating a request for permission
On Thu, Feb 26, 2015 at 11:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
We may have a universal way for functions to self reference themselves i
post ES6.
+1 this
- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
I miss you `arguments.callee`, specially in this fat arrows era where
most of the time developers don't even care about removing listeners.
Apologies for the laud thought and Best Regards
On Thu, Feb 26, 2015 at 4:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 26, 2015, at 4:10
On Feb 26, 2015, at 4:10 AM, Leon Arnott wrote:
The twitter thread starts here:
https://twitter.com/getify/status/570614952605560838 and basically boils down
to the observation that this:
```
({ f() { return f; }}.f()) /* ReferenceError (probably) */
```
is not semantically identical to
On Wed, Feb 25, 2015 at 11:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The automatically provided ‘name’ property of function objects has the
attributes writable: false, configurable true. That means that its value
can be modified using Object.defineProperty or deleted using the
In the past 'throw' statements have caused a deopt for the enclosing
function in v8 and spidermonkey. I think they still do in some
scenarios. I would assume that if a statement is able to throw the
enclosing function must have unwind logic and it could potentially
suppress inlining as well
that's true!
I miss that too!
We are working on a framework for the company here, and sometimes, getting
the callee would be really useful, and we simply can't!!!
Removing the arguments.caller/calee could make more sense if, like other
features, had been replaced by another syntax.
What was the
On Thu, Feb 26, 2015 at 6:48 PM, Katelyn Gadd k...@luminance.org wrote:
In the past 'throw' statements have caused a deopt for the enclosing
function in v8 and spidermonkey. I think they still do in some
scenarios. I would assume that if a statement is able to throw the
enclosing function
Jeff?
On Thu, Feb 26, 2015 at 9:48 AM, Katelyn Gadd k...@luminance.org wrote:
In the past 'throw' statements have caused a deopt for the enclosing
function in v8 and spidermonkey. I think they still do in some
scenarios. I would assume that if a statement is able to throw the
enclosing
On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
`callee` could be spec'd similar to `super` and transpiled or resolved
statically instead of dynamically, but `callee.caller` or in general the
function `caller` raised many security concerns, giving you
It looks like Dave is taking another approach to this problem with a
SharedArrayBuffer idea:
https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/
He then builds something similar to what I want on top of it:
https://gist.github.com/dherman/5463054
Interesting
To respond to this, I searched in vain for the following message on
es-discuss, only to find it in a private thread. This message helped
contribute towards the syntactic direction we finally took, where allowable
new meta-accesses are introduces by keyword.identifier, but only for
keywords
`callee` could be spec'd similar to `super` and transpiled or resolved
statically instead of dynamically, but `callee.caller` or in general the
function `caller` raised many security concerns, giving you the ability to
reach objects you probably shouldn't have.
These two were different beasts,
Seems like a bug. You can just profile whether the exceptional path was ever
taken; if it wasn't then speculate that accesses are in-bounds. Boom, you have
a fast in-bounds check and the optimizing JIT doesn't have to know anything
about what happens on out-of-bounds (i.e. it could throw
In nodejs you can require a json file directly to get its value: `var value =
require(“./package.json”)`.
Is there an equivalent construct in es2015? Or developers have to turn it into
a module before it can be imported?
___
es-discuss mailing list
Glen, better to ask this question on
https://github.com/whatwg/loader/issues/new
https://github.com/whatwg/loader/issues/new, we will be happy to provide more
details since this has nothing to do with ES2015 specifications.
/caridy
On Feb 26, 2015, at 3:24 AM, Glen Huang curvedm...@gmail.com
Oh, didn’t know it’s loader’s responsibility. Will give the spec a read
(haven’t read it throughly) and post to the issue track if I can’t figure it
out.
But just to make sure I will ask the right question, we should write something
like `import value from “./package.json”;` in es2015, and
The twitter thread starts here:
https://twitter.com/getify/status/570614952605560838 and basically boils
down to the observation that this:
```
({ f() { return f; }}.f()) /* ReferenceError (probably) */
```
is not semantically identical to this:
```
({ f: function f() { return f; } }.f()) /*
Was this discussed? I can't find any reference to it.
On Mon, Dec 22, 2014 at 1:34 AM, Gary Guo nbdd0...@hotmail.com wrote:
If added, it can help ES engines to write more code in ES instead of
native languages. So +1 as well.
___
es-discuss
Here is a new proposal for some additional meta properties that should be
considered for ES7
https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
I've added this to the agenda for next months TC39 meeting but pre-meeting
discussion is always welcomed right here.
Allen
On 02/26/2015 09:54 AM, Mark S. Miller wrote:
Jeff?
To be completely honest, I can't answer this. My message was merely to pass
along the sentiments of others, observed elsewhere, not previously communicated
to this list. I personally don't understand what we're doing at a low level
agreed ... between `self` and `callee` probably `self` is better. Anyone
with a different/new idea?
On Thu, Feb 26, 2015 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache claude.pa...@gmail.com
wrote:
Alternative name for `function.callee`:
On Thu, Feb 26, 2015 at 2:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I send a new topic message about the following, but for some reason it
seems slow getting to es-discuss. So, I'm trying it via a replay:
Here is a new proposal for some additional meta properties that should be
I send a new topic message about the following, but for some reason it seems
slow getting to es-discuss. So, I'm trying it via a replay:
Here is a new proposal for some additional meta properties that should be
considered for ES7
https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
Sorry if there was any confusion earlier, but throw-on-OOB semantics is
easier from an AOT/asm.js-compilation POV. Ideally, typed arrays would
throw on all OOB, but I realize that isn't web compatible at this point.
On Wed, Feb 25, 2015 at 6:40 PM, Jeff Walden jwalden...@mit.edu wrote:
FWIW, that looks great to me Allen, thanks for writing that down!
I specially like that it's going to take just about 22 years before
`arguments` will be usable as Array ... eh eh eh, about the time :D
Best Regards
On Thu, Feb 26, 2015 at 10:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
I personally wouldn't mind `self` but it has been historically used as
context or global reference, while callee ... you don't probably need to
explain what's that about.
On the other hand, from `arguments` object, `callee`was more semantic but
it feels not th ebest choice from `function` indeed.
I think it's easier to convey the message to never use callee instead use
function.self.
On Feb 27, 2015 1:52 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
((n)=n1? n*function.callee(n-1) : 1)
On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote:
Can you show an example of how callee
function.current?
From: Andrea Giammarchimailto:andrea.giammar...@gmail.com
Sent: 2015-02-26 18:56
To: Tab Atkins Jr.mailto:jackalm...@gmail.com
Cc: es-discussmailto:es-discuss@mozilla.org
Subject: Re: Proposal: Additional Meta Properties for ES7
agreed ...
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
But
function.next -- Current yield result
is awesome! Bravo. It solves a problem which is otherwise really hard to
express.
Actually, another possible name for this that I want to put on the table is:
function.last --- the last
Once you are willing to move beyond callee, there are a whole lot of
available English words:
function.me
function.here
function.this (I kinda like it but I also don't believe it would be a good
choice)
function.target
function.self (suggested by Claude)
function.object (you are accessing
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
For most of these, my first reaction is meh. They all make sense and violate
no principle, but are they worth it?
I do not like the arrow function behavior. For anything named
function.something occurring within an arrow function, I'd
yes, exactly. As a lexical special form, it violates no fundamental
principle.
On Thu, Feb 26, 2015 at 12:22 PM, Kevin Smith zenpars...@gmail.com wrote:
To respond to this, I searched in vain for the following message on
es-discuss, only to find it in a private thread. This message helped
Alternative name for `function.callee`: I find that `function.self` sounds
better in case of recursive call (and probably in other cases as well).
—Claude
Le 26 févr. 2015 à 23:47, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
Here is a new proposal for some additional meta properties
had same thought ... that wouldn't need much explanation neither. +1 here
On Thu, Feb 26, 2015 at 11:59 PM, Domenic Denicola d...@domenic.me wrote:
function.current?
--
From: Andrea Giammarchi andrea.giammar...@gmail.com
Sent: 2015-02-26 18:56
To: Tab Atkins
Can you show an example of how callee is used with a fat arrow function?
(()={alert(callee);})()
Thanks.
On 2/26/15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Here is a new proposal for some additional meta properties that should be
considered for ES7
On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache claude.pa...@gmail.com wrote:
Alternative name for `function.callee`: I find that `function.self` sounds
better in case of recursive call (and probably in other cases as well).
Agreed that callee, while technically accurate, is a clumsy word and
((n)=n1? n*function.callee(n-1) : 1)
On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote:
Can you show an example of how callee is used with a fat arrow function?
(()={alert(callee);})()
Thanks.
On 2/26/15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Here is a new proposal for
Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
For most of these, my first reaction is meh. They all make sense and violate
no principle, but are they worth it?
I do not like the arrow function behavior.
I am positive that there will be good reasons I am just curious what they
might be, why not: `function(){ function(); }`
- Matthew Robb
On Thu, Feb 26, 2015 at 8:00 PM, Tom Schuster t...@schuster.me wrote:
I think it's easier to convey the message to never use callee instead
use
Or the following three forms would be great:
// normal form
function();
// or
function.invoke();
// additionally
function.call();
function.apply();
- Matthew Robb
On Thu, Feb 26, 2015 at 9:29 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I am positive that there will be good reasons I am
45 matches
Mail list logo
