Declaration binding instationationing
There is an English problem here: Let existingProp be the resulting of calling the [[GetProperty]] internal method of go with argument fn. Can the spec be made easier to read? -- Garrett @xkit ChordCycles.com garretts.github.io personx.tumblr.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: {Spam?} Re: Subclassing ES6 objects with ES5 syntax.
Kevin Smith wrote: So what would the ideal Promise.resolve semantics do? I'm not sure, maybe use SpeciesConstructor instead of [[PromiseConstructor]]? This removes the wart in my view, has no less integrity. C. Scott? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
> > Domenic, Kevin: the concern about Reflect.construct seems misplaced, but > in any event, the issue C. Scott raises wants addressing on its own. WDYT? > Yeah, sorry for dwelling on Reflect.construct so much (it's in my mind for other reasons). So what would the ideal Promise.resolve semantics do? I'm not sure, maybe use SpeciesConstructor instead of [[PromiseConstructor]]? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: is an iterator allowed to reuse the same "state" object?
I missed it, thanks.I know things will improve in time but I'm just coming from a discussion with folks complaining about the performance of generators and GC overhead in real code with Chrome and Firefox relative to simple hand written loops. On Tue, Apr 28, 2015 at 4:28 PM, Allen Wirfs-Brock wrote: > > On Apr 28, 2015, at 4:21 PM, John Lenz wrote: > > You would hope that the engines might be able to create these objects on > the stack but I don't think anyone does that yet and the result is a flood > of eden objects. > > I would like to know I'm wrong about this. > > did you see > https://esdiscuss.org/topic/performance-of-iterator-next-as-specified#content-15 > > > A really good optimizing jit should be able to inline the 'next' call, > recognize that the IterationResult object doesn't escape (it knows this for > for-of loops) and not do an allocation at all. > > Allen > > > > On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" > wrote: > >> >> On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: >> >> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz wrote: >> >> By which I mean the object that returns the current value and "done" >> state? >> >> >> IIRC, it's not supposed to. The built-in iterators will return fresh >> objects each time, so there's no mutation hazard. Userland iterators >> can of course violate this, but at their peril. >> >> >> Well, that's not exactly what the ES2015 spec. says. The specification >> of the Iterator interface ( >> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iterator-interface ) >> does not require that the `next` method return a fresh object each time it >> it called. So a userland iterator would not be violating anything by >> reusing a result object. >> >> However, the specifications for all ES2015 built-in iterators require >> that they return fresh objects. >> >> None of the built-in consumers of the Iterator interface (for-of, >> Array.from, etc.) retain references to IteratorResult objects after testing >> for `done` and accessing the `value`, so semantically they don't care >> whether the ResultObject is reused. However, such reuse might preclude some >> otherwise plausible engine level optimizations. >> >> Allen >> >> >> > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: is an iterator allowed to reuse the same "state" object?
On Apr 28, 2015, at 4:21 PM, John Lenz wrote: > You would hope that the engines might be able to create these objects on the > stack but I don't think anyone does that yet and the result is a flood of > eden objects. > > I would like to know I'm wrong about this. > did you see https://esdiscuss.org/topic/performance-of-iterator-next-as-specified#content-15 A really good optimizing jit should be able to inline the 'next' call, recognize that the IterationResult object doesn't escape (it knows this for for-of loops) and not do an allocation at all. Allen > On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" wrote: > > On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: > >> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz wrote: >>> By which I mean the object that returns the current value and "done" state? >> >> IIRC, it's not supposed to. The built-in iterators will return fresh >> objects each time, so there's no mutation hazard. Userland iterators >> can of course violate this, but at their peril. > > Well, that's not exactly what the ES2015 spec. says. The specification of > the Iterator interface > (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iterator-interface > ) does not require that the `next` method return a fresh object each time it > it called. So a userland iterator would not be violating anything by reusing > a result object. > > However, the specifications for all ES2015 built-in iterators require that > they return fresh objects. > > None of the built-in consumers of the Iterator interface (for-of, Array.from, > etc.) retain references to IteratorResult objects after testing for `done` > and accessing the `value`, so semantically they don't care whether the > ResultObject is reused. However, such reuse might preclude some otherwise > plausible engine level optimizations. > > Allen > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: is an iterator allowed to reuse the same "state" object?
You would hope that the engines might be able to create these objects on the stack but I don't think anyone does that yet and the result is a flood of eden objects. I would like to know I'm wrong about this. On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" wrote: > > On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: > > On Mon, Apr 27, 2015 at 3:11 PM, John Lenz wrote: > > By which I mean the object that returns the current value and "done" state? > > > IIRC, it's not supposed to. The built-in iterators will return fresh > objects each time, so there's no mutation hazard. Userland iterators > can of course violate this, but at their peril. > > > Well, that's not exactly what the ES2015 spec. says. The specification of > the Iterator interface ( > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iterator-interface ) > does not require that the `next` method return a fresh object each time it > it called. So a userland iterator would not be violating anything by > reusing a result object. > > However, the specifications for all ES2015 built-in iterators require > that they return fresh objects. > > None of the built-in consumers of the Iterator interface (for-of, > Array.from, etc.) retain references to IteratorResult objects after testing > for `done` and accessing the `value`, so semantically they don't care > whether the ResultObject is reused. However, such reuse might preclude some > otherwise plausible engine level optimizations. > > Allen > > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
C. Scott Ananian wrote: It seems to me that this is an incomplete feature that should have been dropped from the spec. Seems like. I apologize for not noticing this sooner. No need -- thanks for finding it. Domenic, Kevin: the concern about Reflect.construct seems misplaced, but in any event, the issue C. Scott raises wants addressing on its own. WDYT? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
On Apr 28, 2015, at 1:08 PM, Kevin Smith wrote: > > What is the use case for third argument to Reflect.construct? The primary use case is emulating the super() call semantics in a Proxy construct trap handler. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
> > So, ES6 Promises reflect a specific set of design decisions, including a > specific definition of "same type" that appears to exist solely for use by > Promise.resolve. All that design guarantees is that the object has an > certain specific internal slot whose value is tested in a specific way by > Promise.resolve. It doesn't guarantee that the object is a well-promise or > that it has any specific other characteristics that are expected of Foo > objects. It's hard to extrapolate from that specific design to the > underlying intent of the designer. > I don't see any rational intent for the current design other than: Only return x if x was **constructed** by C. The current semantic is: Only return x if x was constructed by C, or any code with a reference to C arbitrarily chose that it should appear to have been constructed by C. Allowing an object to pass a nominal type test for a constructor, where the object was not initialized by that constructor seems bad. What is the use case for third argument to Reflect.construct? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
On Tue, Apr 28, 2015 at 2:41 PM, Allen Wirfs-Brock wrote: > So, ES6 Promises reflect a specific set of design decisions, including a > specific definition of "same type" that appears to exist solely for use by > Promise.resolve. All that design guarantees is that the object has an > certain specific internal slot whose value is tested in a specific way by > Promise.resolve. It doesn't guarantee that the object is a well-promise or > that it has any specific other characteristics that are expected of Foo > objects. It's hard to extrapolate from that specific design to the > underlying intent of the designer. > I think this is exactly my point. I understand what the original intent was, but the result is (it seems to me) a wart. `Promise.resolve` now uses its own idiosyncratic definition for "same type" which isn't shared by any other JavaScript objects. What's more, it's not clear that its idiosyncratic definition actually accomplishes what it was meant to. It seems to me that this is an incomplete feature that should have been dropped from the spec. I apologize for not noticing this sooner. Folks who want some sort of "tamper-proof" Promises should probably build them in user-space on top of the other abstractions which are provided. --scott ps. I note that `core-js`/`babel` have already implemented the fix I proposed above, of looking at the prototype chain instead of [[PromiseConstructor]]: https://github.com/zloirock/core-js/blob/v0.9.4/modules/es6.promise.js#L194 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
On Apr 27, 2015, at 8:01 PM, Kevin Smith wrote: > x = Reflect.construct(Promise, x, C); > > is another fine way to fool someone who wrote "C.resolve(x)" and expected to > get an instance of C back. > > Thanks for pointing this out. I believe the ability to use an arbitrary > newTarget parameter for Reflect.construct is breaking the intent of > Promise.resolve. Using an arbitrary "newTarget" is also problematic for the > private fields proposal. > > It seems to me that Reflect.construct has been given a capability that is not > otherwise expressible with ES6 syntax, and that gap is problematic. > > Maybe I've missed some context though. Mark, Allen, any thoughts? Note that the exact same kind of circumvention could have been accomplished with the Promise design prior to instantiation reform adding the 3rd argument to Construct: x = C[Symbol.create]().apply(Promise, x); As to "breaking the intent of Promise.resolve", we have to look closely at what that intent actually is and whether "intent" is equivalent to "guarantee". Apparently the intent of Foo.resolve is to coerce the argument value to a the same type of promise object as produced by the Foo constructor (assuming that Foo is a constructor that inherits from Promise). But "same type" is a very elusive concept of in JS. Is an object that is initially instantiated by Foo still of the "same type" as other objects created by Foo if it has been mutated that such that it no longer has Foo.prototype on its prototype chain and/or shares no properties in common with the other objects created using Foo. If an object created by Foo still the "same type" if additional properties are added to it. What if addiotnal properties are added via subclassing. Why is an instance of a subclass of Foo the "same type" as an instance of Foo. If not, why not? Finally, note Foo.resolve may or may not be the same method as Promise.resolve, so whatever definition of "same type" that is used by Promise.resolve is not necessarily the definition used by Foo.resolve. So, ES6 Promises reflect a specific set of design decisions, including a specific definition of "same type" that appears to exist solely for use by Promise.resolve. All that design guarantees is that the object has an certain specific internal slot whose value is tested in a specific way by Promise.resolve. It doesn't guarantee that the object is a well-promise or that it has any specific other characteristics that are expected of Foo objects. It's hard to extrapolate from that specific design to the underlying intent of the designer. This is the nature of JS objects. There are very few guarantees about anything. If you want guarantees you need to lock things down and probably add code to test for the guaranteed conditions. If you want guarantees, you probably aren't going to use polymeric then-ables or any other form of OO polymorphism. but, it's the developers choice. > > Looking over the Reflect namespace, I also see that Reflect.get and > Reflect.set have been given powers not expressible with syntax: the receiver > does not have to be a prototype parent of the target. > The Receiver argument to these Reflect.get/set/construct is necessary for many Proxy handler use cases. These are simply a reification of the ES MOP api and an important use case of them is to define exotic objects whose behaviors differ from what can be directly expressed using ES language level syntax. It's a trade-up, if you want to allow ES programmer to express things beyond that the syntactic language supports you can't limit that expression to what the syntax allows. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
2015-04-28 5:01 GMT+02:00 Kevin Smith :
> Looking over the Reflect namespace, I also see that Reflect.get and
> Reflect.set have been given powers not expressible with syntax: the
> receiver does not have to be a prototype parent of the target.
>
Did you mean "the receiver does not have to be a prototype [child] of the
target"? I would expect that to be the common case. Anyway, with __proto__
/ setPrototypeOf as part of the language, two objects being in a
parent-child prototype relationship is not an invariant you can always
count on. Additionally, if the property is an accessor, the receiver
argument is passed as the `this` binding into the accessor. But it's easy
enough to call getOwnPropertyDescriptor, extract the getter or setter, and
`call` it with a this-binding that also isn't in a prototype relation with
the object holding the accessor. So, for Reflect.{get|set} at least, I
don't see an issue.
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
Would `new Map(maps.reduce((e, m) => e.concat(Array.from(m)), []))` not
create a new Map from merging an array of `maps`? (It relies on the
`Map.prototype.[Symbol.iterator]` which is `Map#entries`, and the
`iterable` argument of the `Map` constructor)
On Tue, Apr 28, 2015 at 6:06 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Sorry Axel, I was rushing, it sounded over-rude ... so, yes, Map are
> better for words, **but** in this specific case it was about all
> chars/surrogate pairs, that's why I've said Objects where safe ... plus the
> rest, reduce also is very handy for this exact kind of things ;-)
>
> But yes, if it was a owrd counter, I'd use same logic with new Map passed
> instead of {} and the correct .set/.get invoke
>
> Best Regards
>
> On Tue, Apr 28, 2015 at 2:02 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Moreover `undefined|0` is exactly 0. The `|0` is used in asm.js because
>> it explicitly declares the intent.
>>
>> So again, no error in there ;-)
>>
>> Regards
>>
>> On Tue, Apr 28, 2015 at 1:58 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> Now you read again the "exercise" and realize that's impossible to have
>>> as a piutfall ... no, I just used a KISS approach for what I can tell, no
>>> pitfalls with one single surrogate could happen by specs.
>>>
>>> Best Regards
>>>
>>> On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer
>>> wrote:
>>>
With Maps, there are less pitfalls. For example: what if you want to
use your version to count words and one of the words is `__proto__`? Most
pitfalls can be fixed via `Object.create(null)`, but Maps are more
straightforward for data (vs. code).
But your version can be easily adapted to Maps, I like the way you use
`reduce()`. The `|` should be a `||`.
On 28 Apr 2015, at 14:31 , Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
Not sure why everyone went for the `Map` version when in JS every
object is basically the equivalent of a `Map` already :-)
```js
let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)),
m), {});
```
looks a win to me, if you need to check or drop chars from the string I
would probably do it once before passing that to `Array.from`
Agreed with Kevin this is rather a StackOverflow like question :-)
Best Regards
On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith
wrote:
> Another option:
>
> var map = new Map;
> Array.from("mainn")
> .map(c => c.toLowerCase())
> .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>
> This kind of question is probably better left for StackOverflow,
> however.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Subclassing ES6 objects with ES5 syntax.
> Le 26 avr. 2015 à 00:58, Kevin Smith a écrit : > > If we used "x.constructor" to determine the actual constructor, then someone > could just change the "constructor" property for x and fool someone who wrote > "C.resolve(x)" and expected to get an instance of C back. Note that if you want to protect yourself against tampering the `constructor` property, you should seriously consider to protect yourself against tampering the `then` property. That means that you should at the very least execute `preventExtensions` on your promise anyway. —Claude___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
Sorry Axel, I was rushing, it sounded over-rude ... so, yes, Map are better
for words, **but** in this specific case it was about all chars/surrogate
pairs, that's why I've said Objects where safe ... plus the rest, reduce
also is very handy for this exact kind of things ;-)
But yes, if it was a owrd counter, I'd use same logic with new Map passed
instead of {} and the correct .set/.get invoke
Best Regards
On Tue, Apr 28, 2015 at 2:02 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Moreover `undefined|0` is exactly 0. The `|0` is used in asm.js because it
> explicitly declares the intent.
>
> So again, no error in there ;-)
>
> Regards
>
> On Tue, Apr 28, 2015 at 1:58 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Now you read again the "exercise" and realize that's impossible to have
>> as a piutfall ... no, I just used a KISS approach for what I can tell, no
>> pitfalls with one single surrogate could happen by specs.
>>
>> Best Regards
>>
>> On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer
>> wrote:
>>
>>> With Maps, there are less pitfalls. For example: what if you want to use
>>> your version to count words and one of the words is `__proto__`? Most
>>> pitfalls can be fixed via `Object.create(null)`, but Maps are more
>>> straightforward for data (vs. code).
>>>
>>> But your version can be easily adapted to Maps, I like the way you use
>>> `reduce()`. The `|` should be a `||`.
>>>
>>> On 28 Apr 2015, at 14:31 , Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> Not sure why everyone went for the `Map` version when in JS every object
>>> is basically the equivalent of a `Map` already :-)
>>>
>>> ```js
>>> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)),
>>> m), {});
>>> ```
>>>
>>> looks a win to me, if you need to check or drop chars from the string I
>>> would probably do it once before passing that to `Array.from`
>>>
>>> Agreed with Kevin this is rather a StackOverflow like question :-)
>>>
>>> Best Regards
>>>
>>>
>>> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith
>>> wrote:
>>>
Another option:
var map = new Map;
Array.from("mainn")
.map(c => c.toLowerCase())
.forEach(c => map.set(c, (map.get(c) | 0) + 1));
This kind of question is probably better left for StackOverflow,
however.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> --
>>> Dr. Axel Rauschmayer
>>> a...@rauschma.de
>>> rauschma.de
>>>
>>>
>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
Moreover `undefined|0` is exactly 0. The `|0` is used in asm.js because it
explicitly declares the intent.
So again, no error in there ;-)
Regards
On Tue, Apr 28, 2015 at 1:58 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Now you read again the "exercise" and realize that's impossible to have as
> a piutfall ... no, I just used a KISS approach for what I can tell, no
> pitfalls with one single surrogate could happen by specs.
>
> Best Regards
>
> On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer
> wrote:
>
>> With Maps, there are less pitfalls. For example: what if you want to use
>> your version to count words and one of the words is `__proto__`? Most
>> pitfalls can be fixed via `Object.create(null)`, but Maps are more
>> straightforward for data (vs. code).
>>
>> But your version can be easily adapted to Maps, I like the way you use
>> `reduce()`. The `|` should be a `||`.
>>
>> On 28 Apr 2015, at 14:31 , Andrea Giammarchi
>> wrote:
>>
>> Not sure why everyone went for the `Map` version when in JS every object
>> is basically the equivalent of a `Map` already :-)
>>
>> ```js
>> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m),
>> {});
>> ```
>>
>> looks a win to me, if you need to check or drop chars from the string I
>> would probably do it once before passing that to `Array.from`
>>
>> Agreed with Kevin this is rather a StackOverflow like question :-)
>>
>> Best Regards
>>
>>
>> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith
>> wrote:
>>
>>> Another option:
>>>
>>> var map = new Map;
>>> Array.from("mainn")
>>> .map(c => c.toLowerCase())
>>> .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>>>
>>> This kind of question is probably better left for StackOverflow, however.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> --
>> Dr. Axel Rauschmayer
>> a...@rauschma.de
>> rauschma.de
>>
>>
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
Now you read again the "exercise" and realize that's impossible to have as
a piutfall ... no, I just used a KISS approach for what I can tell, no
pitfalls with one single surrogate could happen by specs.
Best Regards
On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer wrote:
> With Maps, there are less pitfalls. For example: what if you want to use
> your version to count words and one of the words is `__proto__`? Most
> pitfalls can be fixed via `Object.create(null)`, but Maps are more
> straightforward for data (vs. code).
>
> But your version can be easily adapted to Maps, I like the way you use
> `reduce()`. The `|` should be a `||`.
>
> On 28 Apr 2015, at 14:31 , Andrea Giammarchi
> wrote:
>
> Not sure why everyone went for the `Map` version when in JS every object
> is basically the equivalent of a `Map` already :-)
>
> ```js
> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m),
> {});
> ```
>
> looks a win to me, if you need to check or drop chars from the string I
> would probably do it once before passing that to `Array.from`
>
> Agreed with Kevin this is rather a StackOverflow like question :-)
>
> Best Regards
>
>
> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith wrote:
>
>> Another option:
>>
>> var map = new Map;
>> Array.from("mainn")
>> .map(c => c.toLowerCase())
>> .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>>
>> This kind of question is probably better left for StackOverflow, however.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
With Maps, there are less pitfalls. For example: what if you want to use your
version to count words and one of the words is `__proto__`? Most pitfalls can
be fixed via `Object.create(null)`, but Maps are more straightforward for data
(vs. code).
But your version can be easily adapted to Maps, I like the way you use
`reduce()`. The `|` should be a `||`.
> On 28 Apr 2015, at 14:31 , Andrea Giammarchi
> wrote:
>
> Not sure why everyone went for the `Map` version when in JS every object is
> basically the equivalent of a `Map` already :-)
>
> ```js
> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m), {});
> ```
>
> looks a win to me, if you need to check or drop chars from the string I would
> probably do it once before passing that to `Array.from`
>
> Agreed with Kevin this is rather a StackOverflow like question :-)
>
> Best Regards
>
>
> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith > wrote:
> Another option:
>
> var map = new Map;
> Array.from("mainn")
> .map(c => c.toLowerCase())
> .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>
> This kind of question is probably better left for StackOverflow, however.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Merge map values
I agree this is not about the ES6 spec. But the answers helped because I was
trying to understand ES6’s arrow function that is similar to lambdas.
Thanks.
From: Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
Sent: Tuesday, April 28, 2015 6:02 PM
To: Kevin Smith
Cc: Axel Rauschmayer; Radhakrishnan, Mohan (Cognizant); es-discuss list
Subject: Re: Merge map values
Not sure why everyone went for the `Map` version when in JS every object is
basically the equivalent of a `Map` already :-)
```js
let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m), {});
```
looks a win to me, if you need to check or drop chars from the string I would
probably do it once before passing that to `Array.from`
Agreed with Kevin this is rather a StackOverflow like question :-)
Best Regards
On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith
mailto:zenpars...@gmail.com>> wrote:
Another option:
var map = new Map;
Array.from("mainn")
.map(c => c.toLowerCase())
.forEach(c => map.set(c, (map.get(c) | 0) + 1));
This kind of question is probably better left for StackOverflow, however.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient(s), please reply to the sender and
destroy all copies of the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email,
and/or any action taken in reliance on the contents of this e-mail is strictly
prohibited and may be unlawful. Where permitted by applicable law, this e-mail
and other e-mail communications sent to and from Cognizant e-mail addresses may
be monitored.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
Not sure why everyone went for the `Map` version when in JS every object is
basically the equivalent of a `Map` already :-)
```js
let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m),
{});
```
looks a win to me, if you need to check or drop chars from the string I
would probably do it once before passing that to `Array.from`
Agreed with Kevin this is rather a StackOverflow like question :-)
Best Regards
On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith wrote:
> Another option:
>
> var map = new Map;
> Array.from("mainn")
> .map(c => c.toLowerCase())
> .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>
> This kind of question is probably better left for StackOverflow, however.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
Another option:
var map = new Map;
Array.from("mainn")
.map(c => c.toLowerCase())
.forEach(c => map.set(c, (map.get(c) | 0) + 1));
This kind of question is probably better left for StackOverflow, however.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
The best I can come up with is a totally different, less functional approach:
```js
const s = 'mainn';
let map = new Map();
for (let ch of s) {
ch = ch.toLowerCase();
const prevCount = map.get(ch) || 0;
map.set(ch, prevCount+1);
}
```
> On 28 Apr 2015, at 10:52 ,
> wrote:
>
> Hi,
>
> I am using ES6 by transpiling. The features remind me of Java lambdas.
>
> If I have a string ‘mainn’ then my map should contain this.
>
> [a=1, i=1, m=1, n=2]
>
> Java : Example. I may not need the TreeMap here.
>
> String s = "__mainn__".replaceAll("[^a-z\\s]", "");
>
>
> final Map count = s.chars().
> map(Character::toLowerCase).
> collect(TreeMap::new, (m, c) -> m.merge((char) c, 1, Integer::sum),
> Map::putAll);
>
> What could be the es6 equivalent ?
>
> Thanks,
> Mohan
> This e-mail and any files transmitted with it are for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. If you are not the intended recipient(s), please reply to the
> sender and destroy all copies of the original message. Any unauthorized
> review, use, disclosure, dissemination, forwarding, printing or copying of
> this email, and/or any action taken in reliance on the contents of this
> e-mail is strictly prohibited and may be unlawful. Where permitted by
> applicable law, this e-mail and other e-mail communications sent to and from
> Cognizant e-mail addresses may be monitored.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Merge map values
It could be something like this. But if this is done internall then we don't
need code to explicitly manipulate the Map.
let m = new Map();
m.set("x",1);
//set other keys
//for (let value of m.entries()){
//if (Object.keys(m).every((key) => m[key] == value[key])){
//Merge
//}
//}
}
Thanks,
Mohan
From: Radhakrishnan, Mohan (Cognizant)
Sent: Tuesday, April 28, 2015 2:23 PM
To: 'es-discuss@mozilla.org'
Subject: Merge map values
Hi,
I am using ES6 by transpiling. The features remind me of Java lambdas.
If I have a string 'mainn' then my map should contain this.
[a=1, i=1, m=1, n=2]
Java : Example. I may not need the TreeMap here.
String s = "__mainn__".replaceAll("[^a-z\\s]", "");
final Map count = s.chars().
map(Character::toLowerCase).
collect(TreeMap::new, (m, c) -> m.merge((char) c, 1, Integer::sum),
Map::putAll);
What could be the es6 equivalent ?
Thanks,
Mohan
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient(s), please reply to the sender and
destroy all copies of the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email,
and/or any action taken in reliance on the contents of this e-mail is strictly
prohibited and may be unlawful. Where permitted by applicable law, this e-mail
and other e-mail communications sent to and from Cognizant e-mail addresses may
be monitored.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Merge map values
Hi,
I am using ES6 by transpiling. The features remind me of Java lambdas.
If I have a string 'mainn' then my map should contain this.
[a=1, i=1, m=1, n=2]
Java : Example. I may not need the TreeMap here.
String s = "__mainn__".replaceAll("[^a-z\\s]", "");
final Map count = s.chars().
map(Character::toLowerCase).
collect(TreeMap::new, (m, c) -> m.merge((char) c, 1, Integer::sum),
Map::putAll);
What could be the es6 equivalent ?
Thanks,
Mohan
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient(s), please reply to the sender and
destroy all copies of the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email,
and/or any action taken in reliance on the contents of this e-mail is strictly
prohibited and may be unlawful. Where permitted by applicable law, this e-mail
and other e-mail communications sent to and from Cognizant e-mail addresses may
be monitored.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
