Re: arrow syntax unnecessary and the idea that "function" is too long

2011-05-09 Thread Till Schneidereit
On Mon, May 9, 2011 at 10:40, Kyle Simpson wrote: [snip] > One thing that troubles me about the goal/movement to have a shorter > "function" syntax... It seems like all the examples we exchange for it are, > on principle, single-line functions. From a readability standpoint, I think > it's a lit

Re: An array destructing specification choice

2011-11-05 Thread Till Schneidereit
On Sat, Nov 5, 2011 at 18:10, Allen Wirfs-Brock wrote: > >> What if the RHS doesn't have a length property at all? Or it has one >> with a value that isn't convertible to a number? No need for that >> complexity. > > This case is consistently handled throughtout the ES spec: >    ToInteger( obj.[[

Re: An array destructing specification choice

2011-11-05 Thread Till Schneidereit
On Sat, Nov 5, 2011 at 19:27, Allen Wirfs-Brock wrote: >>>    ToInteger( obj.[[Get]]("length")) >>> evaluates to 0 if length is missing or has a bogus value. >> >> So in your favored solution, would the following example result in x, >> y, and z all being undefined? >> let [x,y,z] = {0:0, 1:1, 2:2

Re: An array destructing specification choice

2011-11-06 Thread Till Schneidereit
On Sun, Nov 6, 2011 at 03:02, Brendan Eich wrote: > On Nov 5, 2011, at 5:52 PM, Allen Wirfs-Brock wrote: > >> On Nov 5, 2011, at 2:34 PM, Brendan Eich wrote: >> >>> On Nov 5, 2011, at 11:27 AM, Allen Wirfs-Brock wrote: >>> > It should, as no length is assumed to mean "length === 0", IIUC, and

Re: An array destructing specification choice

2011-11-07 Thread Till Schneidereit
> I.e., I think the most easily comprehensible behavior is to make array > destructuring treat the RHS as an Array. > It matches the common use-case (actual arrays), it is consistent (does > the same whether you use ... or not), and is easily explainable. I agree with the consistency argument. The

Re: Nov 16 meeting notes

2011-11-23 Thread Till Schneidereit
>> (I survived the Algol68 report. If you want to have only one precise meaning >> for a word, don't borrow one from a natural language. Otherwise just accept >> that in technical usage, a word's meaning(s) may be only loosely connected >> to its natural language meanings.) > > I'm just basing t

Re: ES6 doesn't need opt-in

2012-01-01 Thread Till Schneidereit
While I like the idea of not having multiple versions of ES very much, I fear that this proposal comes with a danger similar to the problems people have with concatenated source files and the "use strict" pragma. While modules nicely solve the problem of tools doing the wrong thing during some buil