Not quite. I did some later thinking, and hage found probably a simpler
solution.
On Mon, Oct 31, 2016, 16:10 Yongxu Ren wrote:
> Isiah,
> The reason for `=` instead of the `do expression` is to write functional
> code without extra syntax. I do not think there are any indistinguishable
> or 've
Isiah,
The reason for `=` instead of the `do expression` is to write functional
code without extra syntax. I do not think there are any indistinguishable
or 'very confusing' case, though I am aware the *Object Property Shorthand`
that been introduced in ES6 might cause some problems.
Here is what
Inline.
On Mon, Oct 31, 2016, 10:33 Boris Zbarsky wrote:
> On 10/31/16 8:42 AM, Isiah Meadows wrote:
> > When the worker has finished loading, so you can send and receive
> messages
>
> OK, what about a worker that when it loads just starts and infinite loop
> and starts sending you messages (bu
Herby Vojčík wrote:
Jan-Ivar Bruaroey wrote:
On 10/28/16 8:39 AM, Bergi wrote:
Jan-Ivar Bruaroey wrote:
If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see
cancelling terminates the chain. If you intersperse non-cancellable
operations, there'd be a delay if cancel is de
Jan-Ivar Bruaroey wrote:
On 10/28/16 8:39 AM, Bergi wrote:
Jan-Ivar Bruaroey wrote:
If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see
cancelling terminates the chain. If you intersperse non-cancellable
operations, there'd be a delay if cancel is detected during those.
On 10/28/16 8:39 AM, Bergi wrote:
Jan-Ivar Bruaroey wrote:
If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see
cancelling terminates the chain. If you intersperse non-cancellable
operations, there'd be a delay if cancel is detected during those.
Yes, that's what I mean. Sur
On 10/31/16 8:42 AM, Isiah Meadows wrote:
When the worker has finished loading, so you can send and receive messages
OK, what about a worker that when it loads just starts and infinite loop
and starts sending you messages (but obviously never expects any
messages from you, since it's in an in
For what it's worth, if the `=` requires a space before it (I disagree that
the semantic ambiguity must exist at assignment - it could simply require
whitespace), that alone would create sufficient context to differentiate.
Compare these two:
```js
a == {} // loose equals, almost always false
a =
I'd have to agree that `=` just feels ugly and slightly wrong for this use
case.
On Sun, Oct 30, 2016, 22:05 Caitlin Potter wrote:
>
>
> > On Oct 30, 2016, at 9:33 PM, David Baldwin <
> david.chris.bald...@gmail.com> wrote:
> >
> > So just to clarify would the non-labeled statements be required
I just specified some basic semantics. That sounds like a good idea, but I
feel it should just remain a WHATWG extension for now. Technically, you can
still manage ids to ensure it ends up properly coordinated (you already had
to do this when working at scale).
On Sun, Oct 30, 2016, 23:44 Park Hye
Inline
On Thu, Oct 27, 2016, 21:42 Boris Zbarsky wrote:
> On 10/27/16 6:18 PM, Isiah Meadows wrote:
> > 1. Add a new `import.fork(script): Promise` method-like
> > expression that loads the worker and resolves when done/rejects if it
> > couldn't for some reason.
>
> What does "done" mean in thi
Hello together,
for advanced processing of capturing groups in regular expression, I'd like
to propose to expose their offsets within the results of executing an
expression on a string.
The complete proposal can be found at
https://github.com/SebastianZ/es-proposal-regexp-capturing-group-offsets.
12 matches
Mail list logo
