re initializing const throws error which is unable to catch

http://jsbin.com/quvujecuro/5/edit?html,js,console Is it the problem with implementation or am I doing something wrong here in terms of philosophy that redeclaring should throw independent of try..catch block around it ? - Boopathi ___ es-discuss mailin

Suggestion: for-of-and loops

Apologies if this isn't the correct forum for this, and please point me the right way if not. The motivation is that it would be useful if one could tersely loop over multiple iterators simultaneously. I think this could be accomplished with a "for-of-and" syntax. Example: let temp = [80, 35, 2

Re: re initializing const throws error which is unable to catch

It is a compile-time error to have a var declaration to conflict with or shadow a block scope declaration. On Feb 14, 2015 1:31 PM, "Boopathi Rajaa" wrote: > http://jsbin.com/quvujecuro/5/edit?html,js,console > > Is it the problem with implementation or am I doing something wrong here > in terms

Re: Suggestion: for-of-and loops

Have you tried writing a combinator which does exactly that? Take a look at zip in python. On Feb 14, 2015 2:52 PM, "Brian Blakely" wrote: > Apologies if this isn't the correct forum for this, and please point me > the right way if not. > > The motivation is that it would be useful if one could t

Re: Suggestion: for-of-and loops

That is basically what I have done in practice. On Sat, Feb 14, 2015 at 2:59 PM, Kevin Smith wrote: > Have you tried writing a combinator which does exactly that? Take a look > at zip in python. > On Feb 14, 2015 2:52 PM, "Brian Blakely" wrote: > >> Apologies if this isn't the correct forum for

Re: Element onResize and onMove events

It's a good API idea, but I think it's pointless to suggest new abstractions when Web Components and Mutation Observers exist. You can custom-roll today (and in short order) a "move" event for all common browsers. New additions to HTML should focus on either expanding its fundamental capability,

extends null

If I’m reading the latest spec draft correctly then ```js class C extends null { } ``` produces the following result: 1. Constructor kind: derived 2. Prototype of `C`: `Function.prototype` 3. Prototype of `C.prototype`: `null` Neither #2 nor #3 seems very useful: * #2 means that a super-constr

Re: extends null

No, the problem is that class C extends X { when X turns out to be null must be an error along exactly these lines. Everywhere else in the language where X is accepted as an expression evaluated to a value, if X evaluates to null, this is the same thing as placing null in that position. Consider:

Re: extends null

But it’s not an error! Either of the following two classes fail later, when you instantiate them, but not right away. ```js const X = null; class C extends X {} class D extends null {} ``` I’m arguing that both produce weird constructors. I’d much prefer an early error. Or dynamically switchin

Re: extends null

On Sat, Feb 14, 2015 at 1:21 PM, Axel Rauschmayer wrote: > But it’s not an error! Either of the following two classes fail later, > when you instantiate them, but not right away. > > ```js > const X = null; > class C extends X {} > > class D extends null {} > ``` > I didn't mean to imply an earl

Re: extends null

> On 14 Feb 2015, at 22:26, Mark S. Miller wrote: > > On Sat, Feb 14, 2015 at 1:21 PM, Axel Rauschmayer > wrote: > But it’s not an error! Either of the following two classes fail later, when > you instantiate them, but not right away. > > ```js > const X = null; > cla

Re: extends null

On Sat, Feb 14, 2015 at 1:45 PM, Axel Rauschmayer wrote: > > On 14 Feb 2015, at 22:26, Mark S. Miller wrote: > > On Sat, Feb 14, 2015 at 1:21 PM, Axel Rauschmayer > wrote: > >> But it’s not an error! Either of the following two classes fail later, >> when you instantiate them, but not right awa