Hi All,
We have been debating how to design errors raised by future W3C specs
to look like. This includes both synchronously and asynchronous APIs.
I.e. both thrown exception objects, and asynchronously reported errors
reported by for example Promises.
We'd like to get TC39s input on which
V8 has no forEach.
On Feb 3, 2014 11:51 PM, Vic9 vic99...@yandex.ru wrote:
There was a SpiderMonkey bug1, and even a patch, for this for quite a
while. The patch now landed and will be in Firefox 29.
V8 got fixed last week too
code.google.com/p/v8/issues/detail?id=3069
but according
On 2/4/14 4:27 AM, Jonas Sicking wrote:
The advantage of A is that it follows the pattern of current JS
errors. The disadvantage is that it clutters the global object with a
lot of error constructor functions which doesn't really provide any
value as far as I can tell.
Don't they allow easy
On Feb 3, 2014, at 8:51 PM, Vic9 wrote:
There was a SpiderMonkey bug1, and even a patch, for this for quite a while.
The patch now landed and will be in Firefox 29.
V8 got fixed last week too
code.google.com/p/v8/issues/detail?id=3069
but according to spec, forEach should call
On Feb 4, 2014, at 6:28 AM, Boris Zbarsky wrote:
On 2/4/14 4:27 AM, Jonas Sicking wrote:
The advantage of A is that it follows the pattern of current JS
errors. The disadvantage is that it clutters the global object with a
lot of error constructor functions which doesn't really provide any
On Mon, Feb 3, 2014 at 4:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/3/14 7:46 PM, Kevin Reid wrote:
It is an extremely bad idea to have the consequences of a function call
depend on properties of the caller rather than of the function and the
arguments.
I agree, but the postMessage
On 2/4/14 12:08 PM, Kevin Reid wrote:
Could not this be done while matching the above principle as follows?
proxyForB, or more precisely the proxy for the function object
(windowB.postMessage), does not actually invoke windowB.postMessage
itself but a corresponding post message from origin A
On Feb 4, 2014, at 1:27 AM, Jonas Sicking wrote:
...
synchronous and asynchronous call chains.
The error objects should test true for |instanceof Error|. I.e. they
should either be of type Error, or of a subclass of it.
However, the standard instanceof behavior isn't friendly to cross
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Allen
Wirfs-Brock al...@wirfs-brock.com
I've designed exception handling systems before and designed and worked with
complex exception hierarchies. My main caveat is that they are somewhat of an
attractive nuisance. It's easy to
On Tue, Feb 4, 2014 at 11:53 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 29, 2014 at 7:33 AM, Kevin Smith zenpars...@gmail.com wrote:
It is, actually, more simplicity. The concept of `Promise.resolve` and
`Promise.chain` is simpler than `Promise.cast` and `Promise.then` (i.e.:
you introduced already CustomEvent interface ... just go CustomError and
add to both a name property ?
```javascript
new CustomError('type', {
name: 'WhateverIsUsedFor',
bubble: false,
detail: ifNeeded_Whatever
});
```
Pros:
1. easy to polyfill
2. works out of the box
3.
On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldron waldron.r...@gmail.com wrote:
Per Resolution
(https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3)
- Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
- Keep then, reject chain (NOT
Tab Atkins Jr. wrote:
On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldronwaldron.r...@gmail.com wrote:
Per Resolution
(https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3)
- Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
This is now bug https://bugs.ecmascript.org/show_bug.cgi?id=2501
I have updated the working draft to normalize -0 keys to +0 in
Map.prototype.set and Set.prototype.add
Allen
On Feb 4, 2014, at 8:12 AM, Allen Wirfs-Brock wrote:
On Feb 3, 2014, at 8:51 PM, Vic9 wrote:
There was a
On Tue, Feb 4, 2014 at 3:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
This is now bug https://bugs.ecmascript.org/show_bug.cgi?id=2501
I have updated the working draft to normalize -0 keys to +0 in
Map.prototype.set and Set.prototype.add
The SpiderMonkey implementation does exactly
Not sure if this is correct, but: This might actually be (perhaps
accidentally) one step closer to allowing promises for thenables in a
cleaner way *if* the need arises in the future.
Since its impossible to create a promise for a promise now, it would be
*theoretically* possible (at some point
Whoops, maybe scratch the monadic part - it would still be impossible to
create a promise for a promise. It would however be possible to protect
thenables.
On Wed, Feb 5, 2014 at 2:17 AM, Gorgi Kosev gorgi.ko...@gmail.com wrote:
Not sure if this is correct, but: This might actually be (perhaps
1. Committee do both / union proposals smell and bloat -- this is a
problem _per se_.
Irony: .then() does both things and there's no way to stop it from doing
both. The do both committee is actually not wanting both, it wants to only
do one thing. We insist, we demand on having a way to NOT do
mfo...@eldergods.com wrote:
#3 is the only point I concede as being even possibly concrete
Then you get a *plonk*, or at least a demeric, for ignoring the very
concrete problem #2: combinators such as .all do not use .chain, they
use .then. Also for ignoring #1 -- it doesn't matter that
Brendan Eich mailto:bren...@mozilla.com
February 4, 2014 at 7:46 PM
Then you get a *plonk*, or at least a demeric,
demerit', of course.
But I'm talking to a fake address. That's pretty bad, it makes me want
to ignore you (*plonk* in USENET terms). Do better quickly, or else
that's the
Wanting something value-ish, featureless, monadic, is a good goal for a
differently named abstraction built on value objects. Promises are not that
abstraction. Do the work to show the win, under a new name (Future?).
I believe the win has already been shown, though: Futures would of course
I like your looking forwards to the future Future, but I really want to
understand the conflict underneath Promises. I'm not trying to selectively
pick issues out, I'm trying to get a general sense for where the conflict
lies that kicked .chain out from complemeting the spec.
The existing
Mark Roberts wrote:
Wanting something value-ish, featureless, monadic, is a good goal
for a differently named abstraction built on value objects.
Promises are not that abstraction. Do the work to show the win,
under a new name (Future?).
I believe the win has already been
mfo...@eldergods.com wrote:
The existing promises library users would be faced with a porting problem
whose size is hard to estimate
Naive go here;
Promise.prototype.then= function(fn){
function recurse(val){
if(val.chain)
val.chain(recurse)
I do believe it meant to say 'cheap words and unreality'. Nothing to care
about.
On Tue, Feb 4, 2014 at 11:04 PM, Brendan Eich bren...@mozilla.com wrote:
mfo...@eldergods.com wrote:
The existing promises library users would be faced with a porting
problem
whose size is hard to
Ryan Scheel wrote:
I do believe it meant to say 'cheap words and unreality'. Nothing to
care about.
Thanks -- makes me not care about replying, you are right!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
26 matches
Mail list logo
