Sorry for the confusion. I was actually referring to
[[OwnPropertyKeys]] returning an Array, as discussed previously:
http://esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-34
Presumably the corresponding proxy trap would change to return an Array as well.
But this is a bit
How about this -- https://gist.github.com/kangax/9698100
Made it loosely based on B.2.1.1 (escape)
--
kangax
On Fri, Mar 21, 2014 at 5:56 PM, Rick Waldron wrote:
>
>
>
> On Fri, Mar 21, 2014 at 4:29 PM, C. Scott Ananian
> wrote:
>
>> Thanks for the back-reference, Kris. So, everyone seemed
On Fri, Mar 21, 2014 at 4:29 PM, C. Scott Ananian wrote:
> Thanks for the back-reference, Kris. So, everyone seemed to be in
> favor of this, it just never got formally added.
>
> @rwaldron, are you interested in championing this for ES7 as well?
>
Not until someone writes something like this:
h
On Fri, Mar 21, 2014 at 4:02 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> the version in agenda is about getOwnPropertyDescriptors ... I thought it
> is relevant to not mess up too much with what same method without the `Own`
> part also because I don't know why, getPropertyDescri
Thanks for the back-reference, Kris. So, everyone seemed to be in
favor of this, it just never got formally added.
@rwaldron, are you interested in championing this for ES7 as well?
--scott
On Fri, Mar 21, 2014 at 12:09 PM, Kris Kowal wrote:
> Continuing a 2 year old thread.
>
> http://esdiscu
also ... as side note, why this came back to me when the topic is
Object.values I didn't go off topic, I just asked a clarification of a
mentioned method that has nothing to do with values?
Anyway ... off the thread again, I didn't mean to bring irrelevant
discussions in here ... Cheers
On Fri,
the version in agenda is about getOwnPropertyDescriptors ... I thought it
is relevant to not mess up too much with what same method without the `Own`
part also because I don't know why, getPropertyDescriptors, would return an
Array, except just as simulation of the Java meaning?
Or rephrasing: wha
On Fri, Mar 21, 2014 at 12:48 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> getPropertyDescriptors should not return an array at all but an object
> with all keys/symbols so it can be reused to defineProperties later on ...
> right?
>
> 'cause I don't see why getPropertyDescriptors
On Mar 21, 2014, at 7:14 AM, Kevin Smith wrote:
>
> `yield` is a keyword inside `function*` whether you're in strict or
> non-strict code.
>
> Right, but not within the body of nested arrow functions:
>
> function* g() { () => { var yield; } }
>
> IIUC, this would parse fine. So I'm aski
getPropertyDescriptors should not return an array at all but an object with
all keys/symbols so it can be reused to defineProperties later on ... right?
'cause I don't see why getPropertyDescriptors would return an Array
otherwise ..
On Fri, Mar 21, 2014 at 8:32 AM, C. Scott Ananian wrote:
> On
Continuing a 2 year old thread.
http://esdiscuss.org/topic/regexp-escape
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 21 Mar 2014, at 16:38, C. Scott Ananian wrote:
> ```js
> function replaceTitle(title, str) {
> return str.replace(new RegExp(title), "...");
> }
> ```
>
> There ought to be a standard simple way of writing this correctly.
I’ve used something like this in the past:
RegExp.escape = funct
One more for the "it's too late for ES6" train: most other programming
languages have a convenient "safe" way to turn a string into a regular
expression matching that string. `RegExp.escape` is often suggested
as the function name. I think this is worth adding to the standard
library because it h
On Fri, Mar 21, 2014 at 10:10 AM, Jason Orendorff
wrote:
> Because of that, and because Object.keys already returns an array, I
> think Object.values and Object.entries should too.
I agree. This is also consistent with the arrays returned by
getPropertyDescriptors and the proxy trap (which I bel
> `yield` is a keyword inside `function*` whether you're in strict or
> non-strict code.
>
Right, but not within the body of nested arrow functions:
function* g() { () => { var yield; } }
IIUC, this would parse fine. So I'm asking whether a "yield" in the token
stream for an arrow paramete
Hmm. It definitely affects the behavior when properties are added or
removed during iteration.
Map and Set iterators are "live". But then, Map and Set iteration is
fully specified and deterministic. That's not in the cards for
property enumeration. So "live" iterators over object properties
would,
`yield` is a keyword inside `function*` whether you're in strict or
non-strict code.
So that is a syntax error.
-j
On Thu, Mar 20, 2014 at 4:37 PM, Kevin Smith wrote:
> Given the following edge case contained in non-strict code:
>
> function* g() { (yield) => null }
>
> Is this a syntax err
Won't this create a subtle false symmetry? For the collection types,
"keys", "entries", and "values" return iterators, but in this case
"Object.keys" would have to return an array. Does that matter?
___
es-discuss mailing list
es-discuss@mozilla.org
htt
18 matches
Mail list logo
