Re: Letting RegExp method return something iterable?

one lazy hilarious thought on that though ... On Mon, Aug 26, 2013 at 5:30 PM, Forbes Lindesay wrote: > `String#split` already is iterable because it returns an array. What it > isn't is **lazy**. > > > > it's straight forward to make String#split

Re: Letting RegExp method return something iterable?

to be really honest, most people will get it wrong regardless since thanks to JSLint and friends they are use to declare everything on top and they probably forgot for accepts `var` declarations. I've never ever needed this syntax and I don't see the miracle. I am sure somebody one day will use th

Re: Letting RegExp method return something iterable?

Forbes Lindesay wrote: `String#split` already is iterable because it returns an array. What it isn't is **lazy**. To be equivalent to the for code, the let needs to go inside the body of the while, not outside. This neatly demonstrates the key point: - as it stands, writing this kind of c

Non-extensibility of Typed Arrays

So I noticed in the last revision to the TA spec that a decision was made to prevent extensibility of them. Can someone say why that decision was made? It makes TAs somewhat unique vs. all other builtin types and doesn't match the behavior of Blink or WebKit implementations. While I am usually

Re: Letting RegExp method return something iterable?

`String#split` already is iterable because it returns an array. What it isn't is **lazy**. To be equivalent to the for code, the let needs to go inside the body of the while, not outside. This neatly demonstrates the key point: - as it stands, writing this kind of code tends to be bug prone

Re: Letting RegExp method return something iterable?

```javascript {let m; while(m = re.exec(str)) { // ... no, really }} ``` I don't get the need of this but if this is the trend then String#split needs an iterable too (no!) On Mon, Aug 26, 2013 at 4:23 PM, Brendan Eich wrote: > Andrea Giammarchi wrote: > >> Is it very useful because you wro

Re: Letting RegExp method return something iterable?

Andrea Giammarchi wrote: Is it very useful because you wrote for instead of while ? ```javascript while (m = re.exec(str)) console.log(m[0]) ; ``` It is, for two reasons: 1. in JS only for can have a let or var binding in the head. 2. the utility extends to all for-of variations: array com

Re: Letting RegExp method return something iterable?

Is it very useful because you wrote for instead of while ? ```javascript while (m = re.exec(str)) console.log(m[0]) ; ``` I don't really see any concrete advantage, sorry, but maybe it's me not liking at all this `iterable all the things` new trend. On Mon, Aug 26, 2013 at 11:33 AM, Erik Arvi

Re: Unscopeable

On Aug 26, 2013, at 1:38 PM, Erik Arvidsson wrote: > On Mon, Aug 26, 2013 at 3:02 PM, Allen Wirfs-Brock > wrote: >> >> On Aug 26, 2013, at 11:37 AM, Erik Arvidsson wrote: >> >>> I agree that this is crucial. I think that tips the balance over to >>> have to do the Get of @@unscopable on every

Re: Unscopeable

On Mon, Aug 26, 2013 at 3:02 PM, Allen Wirfs-Brock wrote: > > On Aug 26, 2013, at 11:37 AM, Erik Arvidsson wrote: > >> I agree that this is crucial. I think that tips the balance over to >> have to do the Get of @@unscopable on every HasBinding. > > How so. The timing of the @@unscopable property

Re: Unscopeable

On Aug 26, 2013, at 11:37 AM, Erik Arvidsson wrote: > I agree that this is crucial. I think that tips the balance over to > have to do the Get of @@unscopable on every HasBinding. How so. The timing of the @@unscopable property and the the process of using it to filter identifier binding are c

Re: Unscopeable

I agree that this is crucial. I think that tips the balance over to have to do the Get of @@unscopable on every HasBinding. On Mon, Aug 26, 2013 at 1:42 PM, Brendan Eich wrote: > Andreas Rossberg wrote: >> >> So it seems to me that it's wrong to apply an @@unscopable black list >> to arbitrary ob

Re: Letting RegExp method return something iterable?

On Mon, Aug 26, 2013 at 1:05 PM, Andrea Giammarchi wrote: > Long story short, I don't see any real use/case or any concrete advantage > with those examples so please make it more clear what's the problem you are > trying to solve and how these methods will concretely make our life easier > ^_^ H

Re: Unscopeable

Andreas Rossberg wrote: So it seems to me that it's wrong to apply an @@unscopable black list to arbitrary objects in the inheritance chain. It should only filter properties found on its own object. Great point. /be ___ es-discuss mailing list es-dis

Re: Letting RegExp method return something iterable?

you don't need to reset the `lastIndex` to zero if you don't break the loop before unless you are sharing that regexp with some other part of code you don't control. What I am saying is that the example is very wrong as it is since there's no way to have an unsafe `regexES5` behavior in there. Mo

Re: AP2 makes laziness easy.

On Mon, Aug 26, 2013 at 8:54 AM, Mark S. Miller wrote: > Since today this code will still typically work, and will in the near future > successfully become lazier, we should expect a lot of such code to exist by > the time we roll out our new standard. This brings us back to our need to > chose be

Re: AP2 makes laziness easy.

On Mon, Aug 26, 2013 at 12:54 PM, Mark S. Miller wrote: > Since today this code will still typically work, and will in the near > future successfully become lazier, we should expect a lot of such code to > exist by the time we roll out our new standard. This brings us back to our > need to chose

Re: AP2 makes laziness easy.

On Mon, Aug 26, 2013 at 9:22 AM, Mark S. Miller wrote: > On Mon, Aug 26, 2013 at 9:17 AM, Tab Atkins Jr. > wrote: >> What about .resolve()? > > pseudocode: > > resolve(obj) => isPromise(obj) ? adopt(obj) : accept(obj) > > The isPromise above is nominal. If obj is a non-promise thenable,

Re: Killing `Promise.fulfill`

On Mon, Aug 26, 2013 at 7:47 AM, Mark Miller wrote: > If we do call the coercer Promise.from, as should rename the acceptor > Promise.accept rather than Promise.of. If we want an Array coercer rather > than an Array copier, we should consider renaming Array.from to Array.as. I oppose naming the "

Re: AP2 makes laziness easy.

On Mon, Aug 26, 2013 at 9:17 AM, Tab Atkins Jr. wrote: > On Mon, Aug 26, 2013 at 8:54 AM, Mark S. Miller > wrote: > > Since today this code will still typically work, and will in the near > future > > successfully become lazier, we should expect a lot of such code to exist > by > > the time we ro

Re: AP2 makes laziness easy.

On Mon, Aug 26, 2013 at 8:54 AM, Mark S. Miller wrote: > I was recently asked: > > (Forwarded with permission) > > I was wondering if I could get your thoughts on delaying request > execution until invocation of 'then.' > > [...] I don't always want an HttpRequest object to make a network > requ

AP2 makes laziness easy.

I was recently asked: (Forwarded with permission) > I was wondering if I could get your thoughts on delaying request execution until invocation of 'then.' > [...] I don't always want an HttpRequest object to make a network request on creation, because > sometimes I merely aggregate the HttpRequest

Re: Killing `Promise.fulfill`

The existing Array.from also copies the array-like, even if it is an array. Clearly such a copying operation is useful. Whether this should be bundled into Array.from, and whether .from is the right name if it is, are valid questions. However, my first reaction is, leave Array.from alone. It is no

Re: Unscopeable

Here is another issue with your proposed (and already spec'ed) semantics: applying @@unscopable across the inheritance chain is a breaking change. Consider the following, fairly innocent ES5 code: var a = [] a.values = "Hello" with (a) { console.log(values) } Under ES5, this happily p

Re: Killing `Promise.fulfill`

What do we think of having "from" be the coercer? By which I mean, change Array.from to return its input if given a true Array (or properly-subclassed one with [[ArrayInitialisationState]] set to true, maybe??). Then Promise.from could follow that semantic, returning the input if it's a true pro

Re: Killing `Promise.fulfill`

Kevin Smith wrote: I don't think you'll want to have divergent behavior for construct vs. call with new APIs. I believe that would go against Allen's approach for new ES6 built in classes, and beyond that, it unnecessarily overloads the API surface. Different operations ought to have differe