Re: Maps with object keys

Thanks, I was starting to feel like I wasn't explaining my issue very well given the other replies. I'm glad we agree this is not something user-code should have to shim for language level collections. I'm working on several projects that perform statistical analysis and I wanted to stick to JavaS

Re: Maps with object keys

On Mon, Feb 17, 2014 at 3:09 PM, Benjamin (Inglor) Gruenbaum wrote: > I'm trying to work with ES6 Map objects and I ran into an interesting > problem. Yes! Well done. We've noticed this too, and considered (a) allowing objects to provide their own hash and equals operations, as in Java and Pytho

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

C. Scott Ananian wrote: Are recordings available? http://www.infoq.com/presentations/State-JavaScript starting at 1:50 Youtube has more. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: eval of let, etc. Was: Re: restrictions on let declarations

Right, let/const/class Allen On Feb 17, 2014, at 2:19 PM, Mark Miller wrote: > No, absolutely not. By "lexical", I took Allen to mean the new reliably > block-local binding forms: "let", "const", "class" > > > On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson > wrote: > I'm getting vary. Does

Status of Array.prototype.contains

Hi, In the latest draft, I see String.prototype.contains, but no Array.prototype.contains I see something about a no-brainer here https://mail.mozilla.org/pipermail/es-discuss/2011-December/019108.html I haven't found a bug on bugs.ecmascript or a mention in the meeting notes. Or was it supe

Re: Maps with object keys

Le 17/02/2014 22:55, Benjamin (Inglor) Gruenbaum a écrit : My issue here is that I want to index on "complex" values. I was under the impression ES6 maps solve amongst others the problem that with objects - keys are only strings. With maps, all native types (string, number, boolean, undefined, n

Re: Maps with object keys

It is straightforward to implement a hash function based map as a subclass of `Map`. Something like: ```js var HashMap = function() { this._map = new Map(); }; HashMap.set = function(key, value) { var hash = key.hashCode(); var list = this._map.get(hash); if (!list) { list = []; this._map.s

Re: eval of let, etc. Was: Re: restrictions on let declarations

No, absolutely not. By "lexical", I took Allen to mean the new reliably block-local binding forms: "let", "const", "class" On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson wrote: > I'm getting vary. Does that mean that you want to change the semantics > since ES5.1? > > > On Mon Feb 17 2014 at 5:

Re: eval of let, etc. Was: Re: restrictions on let declarations

I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller wrote: > +1. > > > On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock > wrote: > > See > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-

Re: eval of let, etc. Was: Re: restrictions on let declarations

+1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock wrote: > See > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation > > > A better statement of the question would be can we agree that lexical > bindings created by eval are always non-deleta

Re: eval of let, etc. Was: Re: restrictions on let declarations

See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already

Re: Maps with object keys

My issue here is that I want to index on "complex" values. I was under the impression ES6 maps solve amongst others the problem that with objects - keys are only strings. I want to index on 2 (or 100) properties - in this example the x and y values. I don't want to iterate the whole collection and

Re: Maps with object keys

I understand the capability of python, but that is done through comprehensions that do not relate to the mapping of key to value. In ES6 the syntax comes out to: ``` let tuple = {x:3,y:5} [for (value of map.entries()) if (Object.keys(tuple).every((tupleKey)=>tuple[tupleKey] == value[tupleKey])) va

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

> It's not the same effect, because `lenVal` could be an object with > valueOf/toString/@toPrimitive side-effects. Point taken. (Although I'm fine with invoking the side effects twice if you're using `this.length` as a default value, since that would be 'unsurprising' if you are looking at the me

Re: eval of let, etc. Was: Re: restrictions on let declarations

In this context, there are two things you might mean by "throws": a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore t

Maps with object keys

I'm trying to work with ES6 Map objects and I ran into an interesting problem. I want to index/group based on several key values. Let's say my original data is something like: ```js [{x:3,y:5,z:3},{x:3,y:4,z:4},{x:3,y:4,z:7},{x:3,y:1,z:1},{x:3,y:5,z:4}] ``` I want to group it based on the x and

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Are recordings available? --scott On Feb 17, 2014 10:26 AM, "Brendan Eich" wrote: > Andreas Rossberg wrote: > >> On 15 February 2014 20:47, Brendan Eich wrote: >> >>> > Using "-Speak" as a stem conjures Orwell. Not good. >>> >> >> Ah, relax. Gilad Bracha even named his own language Newspeak.

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

On Feb 17, 2014, at 12:25 PM, Brendan Eich wrote: > C. Scott Ananian wrote: >> But as you point out, I don't think there's any actual behavior >> change, since everything washes out to `0` at the end. It's just a >> matter of writing a clearer more consistent spec. > > Yet in that light you sti

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

On 2/14/2014 11:40 PM, C. Scott Ananian wrote: On Fri, Feb 14, 2014 at 11:50 AM, André Bargull wrote: I think Scott is requesting this change: https://gist.github.com/anba/6c75c34c72d4ffaa8de7 Yes, although my proposed diff (in the linked bug) was the shorter, "12. If end is undefined, let re

Re: eval of let, etc. Was: Re: restrictions on let declarations

So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval ("let x=5; delete x;"); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: > I'm also fine wit

Re: Another switch

-Messaggio originale- From: Brendan Eich Sent: Wednesday, February 12, 2014 2:00 AM To: Nathan Wall Cc: Giacomo Cau ; es-discuss@mozilla.org Subject: Re: Another switch Definitely good to see new languages being designed and implemented. JS is not going to break compatibility on the

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Andreas Rossberg wrote: On 15 February 2014 20:47, Brendan Eich wrote: > Using "-Speak" as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Yeah, but no "ECMA" -- the double-whammy. Self-mockery is good. I pay my dues (see "wat" played wit

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

C. Scott Ananian wrote: But as you point out, I don't think there's any actual behavior change, since everything washes out to `0` at the end. It's just a matter of writing a clearer more consistent spec. Yet in that light you still have a point, I think. Allen? /be __

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

On Mon, Feb 17, 2014 at 7:08 AM, Claude Pache wrote: > Just a last note. Beyond the philosophical aspect whether arraylikes of > negative length make any sense at all, there is a strong technical issue you > have probably overlooked: For array methods in general, and for the optional > argument

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

Le 14 févr. 2014 à 23:40, C. Scott Ananian a écrit : > On Fri, Feb 14, 2014 at 11:50 AM, André Bargull wrote: >> I think Scott is requesting this change: >> https://gist.github.com/anba/6c75c34c72d4ffaa8de7 > > Yes, although my proposed diff (in the linked bug) was the shorter, > "12. If end i

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Feb 17, 2014, at 4:38 AM, Andreas Rossberg wrote: > On 15 February 2014 21:06, Allen Wirfs-Brock wrote: >> ... >> But remember, prior to ES5, it was closer to Cobolish machine language. No >> structured control, goto's targeting numeric step numbers, intermediate >> results referenced by s

Re: eval of let, etc. Was: Re: restrictions on let declarations

I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin wrote: > Happy to concede to #3 on my end. Just wanted to be clear that it seems > to be optimizing for future happiness vs. least surprising behavior (which > isn't a bad thing). > > > On Mon, Feb 17, 2014 at 10:26 AM, Jorg

Re: eval of let, etc. Was: Re: restrictions on let declarations

Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro wrote: > On 17/02/2014, at 13:42, Andreas Rossberg wrote: > > On 15 February 20

Re: eval of let, etc. Was: Re: restrictions on let declarations

On 17/02/2014, at 13:42, Andreas Rossberg wrote: > On 15 February 2014 06:10, Brendan Eich wrote: >> Allen Wirfs-Brock wrote: >>> >>> Another consideration in the back of my mind is that there may be useful >>> to implementors to knowing that let/const/class declaration are never >>> dynamically

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 15 February 2014 20:47, Brendan Eich wrote: > Using "-Speak" as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Self-mockery is good. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https:/

Re: eval of let, etc. Was: Re: restrictions on let declarations

On 15 February 2014 06:10, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> >> On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: >> >>> > On further reflection, #3 does feel like trying to rewrite the past. >>> > For better or worse, non-strict mode allows declarations to persist past >>> > th

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 15 February 2014 21:06, Allen Wirfs-Brock wrote: > On Feb 15, 2014, at 11:47 AM, Brendan Eich wrote: >> C. Scott Ananian wrote: >>> >>> On Feb 15, 2014 9:13 AM, "Brendan Eich" >> > wrote: >>> > Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's JS