In ES5 there is a concept of array-like, which while probably too relaxed is
really friendly for developers, as we can easily create custom array-like
abstractions and make it consumable to any generic functions, methods that
process array-likes.
In ES6 there's more advanced (and definitely
1 There's no way I can create custom iterator abstraction (How can I can
define MyCustomIterator.prototype[@@iterator] method?).
2. There's no straightforward way to consume iterators in generic way, e.g.
I want to write function that works in similar way as Set constructor, and
accepts any
There will be a public symbol (that you can import from a system module)
that will allow you to do both things.
There's no problem then. Thanks
--
View this message in context:
http://mozilla.6506.n7.nabble.com/Creating-and-consuming-custom-iterators-tp289598p289600.html
Sent from the
Right, my impression is that most of us are in agreement that it would be
extremely useful to have a simple way to loop over the list of matches for a
regular expression and do something with each one. I don't see why @andrea
doesn't see this need (maybe it's not something he's found need to
This test case [1] from SpiderMonkey failed when I applied the latest
spec changes to my ES6 test implementation. Based on the bug report at
[2], this might be another web-compatibility issue - but is that really
the case? Any input appreciated!
Thanks,
André
[1]
On Wed, Aug 28, 2013 at 2:12 AM, Forbes Lindesay for...@lindesay.co.uk wrote:
Right, my impression is that most of us are in agreement that it would be
extremely useful to have a simple way to loop over the list of matches for a
regular expression and do something with each one. I don't see
So you're in favor of returning the Iterable and then having people use
`Array.from` if they need an array?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'm guessing that code like:
```js
var matches = /foo/.execMultipleLazy('str')
for (let match of matches) {
//do something
}
for (let match of matches) {
//do something
}
for (let match of matches) {
//do something
}
```
Would go wrong somehow
Yes. This is a standard Python
It would be nice from a readability point of view if `iteratable.toArray()`
could always be used as a substitute for `Array.from(iteratable)`. Is there a
way that could be neatly achieved? It would also be nice if methods like
`.map` and `.filter` existed on iteratables. C# does this via the
On Aug 28, 2013, at 17:02 , Forbes Lindesay for...@lindesay.co.uk wrote:
It would be nice from a readability point of view if `iteratable.toArray()`
could always be used as a substitute for `Array.from(iteratable)`. Is there
a way that could be neatly achieved?
For me, [ ... iterable ]
Suggestion: a named parameter `ignoreCase`:
$ 'hello world'.contains('WORLD')
false
$ 'hello world'.contains('WORLD', { ignoreCase: true })
true
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
This must have been suggested before, but it would be great to have a built-in
function for quoting text in a RegExp.
For example:
```js
RegExp.quoteText = function (text) {
return text.replace(/[\^\$\\.*+?()[\]{}|]/g, '\\\$');
};
```
If you wanted to be extra thorough, you could include
The thing about `.map` and `.filter` is that it would be easy enough to create
functional versions:
```js
function* map(array, fn) {
for (var x of array) {
yield fn(x)
}
}
```
But harder to create methods:
```js
Iteratable.prototype.map = function(fn) {
for (var x of this) {
Le 28 août 2013 à 17:23, Axel Rauschmayer a...@rauschma.de a écrit :
This must have been suggested before, but it would be great to have a
built-in function for quoting text in a RegExp.
For example:
```js
RegExp.quoteText = function (text) {
return
Note that an equivalent of both `.map` and `.filter` already exists in ES6: its
name is generator expression. For instance:
```
array.filter(pred).map(transf)
```
becomes:
```
(for (let x of iter) if (pred(x)) transf(x))
```
—Claude
Le 28 août 2013 à 17:27, Forbes Lindesay
Perhaps the second argument of `contains`, `startsWith`, and `endsWith`
should be consistent with the second argument of the `RegExp` constructor.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Aug 28, 2013, at 5:09 AM, André Bargull wrote:
This test case [1] from SpiderMonkey failed when I applied the latest spec
changes to my ES6 test implementation. Based on the bug report at [2], this
might be another web-compatibility issue - but is that really the case? Any
input
$ 'Hallo Friedrichstraße'.contains('STRASSE', { ignoreCase: true })
true? false?
$ 'hello İzmir'.contains('İZMİR', { ignoreCase: true })
true? false?
In other words, should ignoreCase be based on Unicode upper case conversion,
lower case conversion, or case folding, with or without locale
On Wed, Aug 28, 2013 at 10:45 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
$ 'Hallo Friedrichstraße'.contains('STRASSE', { ignoreCase: true })
true? false?
$ 'hello İzmir'.contains('İZMİR', { ignoreCase: true })
true? false?
In other words, should ignoreCase be based on
More to Norbert's point though, it should probably use the `iu` flag, not just
the `i` flag.
(Also, you'd need to use the `RegExp.escape` that people keep talking about,
most recently in the `RegExp.quoteText` thread. But that's minor.)
___
On Wed, Aug 28, 2013 at 11:19 AM, Axel Rauschmayer a...@rauschma.de wrote:
Suggestion: a named parameter `ignoreCase`:
$ 'hello world'.contains('WORLD')
false
$ 'hello world'.contains('WORLD', { ignoreCase: true })
true
This would create inconsistency with indexOf and
On Wed, Aug 28, 2013 at 11:02 AM, Forbes Lindesay for...@lindesay.co.ukwrote:
It would be nice from a readability point of view if
`iteratable.toArray()` could always be used as a substitute for
`Array.from(iteratable)`.
Since both Array.from and [..spread] already covers every single
On Wed, Aug 28, 2013 at 2:12 AM, Forbes Lindesay for...@lindesay.co.ukwrote:
a simple way to loop over the list of matches for a regular expression
it's about 10 years or more we have that .. so to make my very personal
statement clear:
I've got 99 problems in JS, make everything an iterator
I completely agree with Rick plus this is what I meant in the other thread
when I've said I don't see the urge/need to deal with Iterators = Arrays
if not ending up with waste of resources as the one proposed here.
Somebody will need to write specs, tests, and implementations while we have
all
quick one: the hyphen has meaning only inside squared brackets and between
ranges ... this has no meaning `[_-]` so doesn't this `[a-]`
On Wed, Aug 28, 2013 at 9:23 AM, Claude Pache claude.pa...@gmail.comwrote:
Le 28 août 2013 à 17:23, Axel Rauschmayer a...@rauschma.de a écrit :
This must
Right, I don't care whether it's lazy. I only care that it exists. Nobody's
crying out for a lazy version of string split (at least not yet anyway). I
have had the issue of needing to loop over all the matches that a regular
expression has. It is a common, recurring issue that many
Forbes Lindesay wrote:
Let’s move on from whether it should exist (clearly it should)
Does String.prototype.match not count?
and stick to whether it should be an array, or lazy. Does anyone have
a strong opinion either way? The fact that all our regular expression
iteration thus far has
The advantage of a lazy execAll, is the ability to break out of the for..of
loop without the need to continue to traverse the input string looking for
matches. This is the same advantage that the `while(m = re.exec())` has going
for it. You can always be greedy by using Array.from or an array
Ron Buckton wrote:
The advantage of a lazy execAll, is the ability to break out of the
for..of loop without the need to continue to traverse the input string
looking for matches. This is the same advantage that the `while(m =
re.exec())` has going for it. You can always be greedy by using
On 08/27/2013 09:35 AM, Oliver Hunt wrote:
My complaint is that this appears to be removing functionality that has been
present in the majority of shipping TA implementations, assuming from LH's
comment that Chakra supports expandos.
Note that even in the engines that support expandos, they
30 matches
Mail list logo
