Here's the part that gets me, though: what is the value of disallowing named
properties on typed arrays? Who does this help?
I don't quite buy that this helps users; most of the objects in your program
are going to allow custom properties to be added at any point. That's kind of
the whole
The fact that s.match(/re/g) returns the array of all matches (with captures)
sucks some of the oxygen away from any /re/g.execAll(s) proposal.
But String.prototype.match has perlish hair (e.g., those capture groups
showing up in the result array).
Really? AFAICT, only the complete
[...] I think this makes a good case for a lazy execAll -- with a much better
name.
Candidates: r.iterate(s), r.iterateOver(s), r.execIterator(s) (blech!).
Suggest some!
I think “exec” should be in the name, to indicate that the new method is a
version of `exec()`.
Ideas:
–
Axel Rauschmayer wrote:
The fact that s.match(/re/g) returns the array of all matches (with
captures) sucks some of the oxygen away from any /re/g.execAll(s)
proposal.
But String.prototype.match has perlish hair (e.g., those capture
groups showing up in the result array).
Really? AFAICT,
Axel Rauschmayer wrote:
– execIter()
Not bad, I think better than execAll, which does not connote return of
an iterator, but which does perversely suggest returning an array of all
exec results.
`execAll()` may not be that bad. It’s not pretty, but it’s fairly easy
to guess what it does
I agree that execAll() is not a 100% winner, more like a clean-up of a quirky
corner. But exec() in “multi” mode has a surprising amount of pitfalls:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator (more of an
anti-pattern, anyway,
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator
(more of an anti-pattern, anyway, but still)
* side effects via lastIndex may be a problem
Anything we do of the execAll/execIter kind had better be immune
On 28 August 2013 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? It would also be nice if methods
On Thu, Aug 29, 2013 at 4:13 AM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator (more
of an anti-pattern, anyway, but still)
* side effects via lastIndex may be
This all seems fair enough. My concern is mostly that the `blob.method(fn)`
syntax seems much easier to get your head around (as someone familiar to
JavaScript) than the `[for (let x of iter) if (pred(x) transf(x)]`. I always
used the traditional syntax for LINQ in C# as well (which gave you
plus any time you want you can `GenericPrototype.toArray =
function(){return Array.from(this)};` ... no need to put in specs your C#
flavor, somebody else Python flavor, Ruby, Java, or Haskell ... JS would
look like the tower of babel ^_^
note: it kinda does already in specs V6 and early 7
On
On Aug 29, 2013, at 1:13 AM, Brendan Eich bren...@mozilla.com wrote:
Axel Rauschmayer wrote:
* /g flag must be set
* lastIndex must be 0
* can’t inline the regex, because it is needed as a pseudo-iterator (more of
an anti-pattern, anyway, but still)
* side effects via lastIndex may be a
then you are probably looking for something like this?
```javascript
String.prototype.matchAll = function (re) {
for (var
re = new RegExp(
re.source,
g +
(re.ignoreCase ? i : ) +
(re.multiline ? m : )
),
a = [],
m; m = re.exec(this);
a.push(m)
);
On Wed, Aug 28, 2013 at 10:19 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
The problem is that in ES6 slice always returned a new Array instance
using the Array of the realm associated with the invoked slice function.
In ES6 slice returns an object that is determine based upon the actual
At the last TC39 meeting we discussed the addition of the following
items[0]:
Number.MAX_SAFE_INTEGER = (2^53)-1
Number.isInteger
- Infinity = false
- NaN = false
- value !== truncated value = false
- -0 = true
Number.isSafeInteger
- -0 = true
This resolution of record doesn't
Quick, possibly silly idea: What if `typeof null` returned `undefined`?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
Nathan Wall wrote:
Alex Rauschmayer wrote:
Quick, possibly silly idea: What if `typeof null` returned `undefined`?
By default or after you flip a switch?
I have a better value objects draft coming, which addresses opt-in
typeof reform (cross-realm!).
In
On Aug 29, 2013, at 10:51 AM, Kevin Reid wrote:
On Wed, Aug 28, 2013 at 10:19 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The problem is that in ES6 slice always returned a new Array instance using
the Array of the realm associated with the invoked slice function. In ES6
slice
I'm not sure the following is a bug, so discussing on es-discuss first
before filing one.
I agree that during the meeting we explicitly discussed MAX_SAFE_INTEGER
but not MIN_SAFE_INTEGER, which is why I wrote presumably in my previous
message. But I think it violates both consistency with the
On Thu, Aug 29, 2013 at 12:56 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Aug 29, 2013, at 10:51 AM, Kevin Reid wrote:
This is a hazardous change for SES-style security. For example, I've just
taken a quick look at our (Caja) codebase and found a place where
On Aug 29, 2013, at 1:39 PM, Kevin Reid wrote:
On Thu, Aug 29, 2013 at 12:56 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Aug 29, 2013, at 10:51 AM, Kevin Reid wrote:
This is a hazardous change for SES-style security. For example, I've just
taken a quick look at our (Caja)
On Thu, Aug 29, 2013 at 2:21 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Of the two cases I refer to, one is a function (the trademarking stamp())
which takes a list of objects as a parameter and needs to ensure that
successive stages of processing operate on exactly the same set of
Kevin Reid wrote:
(I admit I favor composition/delegation over inheritance, for public
interfaces, and therefore dislike the notion of working with
subclasses of concrete built-ins.
+∞
But one could also consider, for example, the reasons why
java.lang.String is final.)
One could also
Dean Landolt wrote:
I'd hate to see it throw. Ignoring lastIndex seems friendlier,
especially if it were called `execAll`. It probably shouldn't be
called `execIter` considering `exec` is already an iterator (even if a
bit crazy).
'exec' is not an iterator in any well-defined ES6 sense.
Oliver Hunt wrote:
I would favor ignoring lastIndex rather than throwing, but to be sure can you
clarify what you mean by global regexp?
One created with the 'g' flag, either literally (/re/g) or via the
constructor (new RegExp(src, 'g')).
If we're talking /.../g, then my feeling is that
25 matches
Mail list logo
