Re: Destructuring object outside of var declaration

On Tue, Sep 17, 2013 at 4:27 PM, Brendan Eich wrote: >> Nathan Wall >> September 17, 2013 10:06 AM >> I'm wondering what the best syntax is for object destructuring outside of >> a var declaration. For instance, the following works in Firefox Nightly and >> Traceur:

Re: ES7 - the standard

(Small typo, the path was changed to , since that is the direction we go for naming.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: ES7 - the standard

> Could the spec next time have a non-normative section with the main changes I agree with Peter. For the purpose of being helpful, I tried making a page related to the changes: , so that it can be linked to. As far as I know, there is only Array.pro

Re: Ideas on type hinting and named parameters

I like that syntax. I wonder about the runtime semantics of it, though. (I know TypeHint is a TODO, but…) Is there any implication at runtime of a function that returns a String? Is this: ```js var point = { x Number, y Number }; ``` … the same as this? ```js var point = { x: Number(),

Re: Reflect.type

On Mon, Jun 8, 2015 at 4:38 PM, Nick Krempel wrote: > On 8 June 2015 at 15:05, Thaddee Tyl wrote: >> Ah! Good. I expected it to fail just like this: >> >> ```js >> function Thing(){} >> function SubThing(){} >> SubThing.prototype = Object.create(Thing) /

Re: Reflect.type

On Sat, Jun 6, 2015 at 6:23 PM, Jordan Harband wrote: > if `class SubThing extends Thing {}`, then `new SubThing instanceof Thing` > would be true. Ah! Good. I expected it to fail just like this: ```js function Thing(){} function SubThing(){} SubThing.prototype = Object.create(Thing) SubThing.pr

Re: Reflect.type

You suggest a list of types of fixed size. The lack of exposition of user-definable value types is a problem you mention. Having a better typeof is not as useful as having a better instanceof. This would be more valuable: ```js isA(42, Number) === true // Doesn't work with instanceof isA([1,3],

Re: why not just import new language into browser?

On Wed, May 27, 2015 at 5:01 PM, 李白|字一日 wrote: > Web Api, Native Client are all the efforts made to make the browser side to > be a platform other than HTML + CSS + JAVASCRIT Parser. Web API (by which I assume you mean the APIs defined in the W3C and WHATWG standards) is definitely not an effort

Renaming test262 (was: JavaScript 2015?)

On Fri, Jan 23, 2015 at 1:05 AM, Brendan Eich wrote: > Andrea Giammarchi wrote: >> I mean ... how should I call my browser that is not 100% compliant with >> HTML5, a fully compliant HTML 1997 browser ? > > Of course this question arose with respect to HTML5, which was nowhere near > "done" (is it

Re: Eval, literal eval, safe eval

Michał: Thanks for pointing this out. Strict mode doesn't quite work like I expected it to. I wonder if anything can be done for that Function('')() behaviour. (Weirdly, I was able to fix the function(){ this.a } behaviour.) Additionally, this technique, at least for now, cannot be applied to the

Re: Eval, literal eval, safe eval

On Sun, Nov 23, 2014 at 12:38 PM, Florian Bösch wrote: > Btw. you can do a sort of sandboxed eval today by overriding all names found > in window. There are some caveats however. The so sandboxed code can still > access (and change) object internals, such as > "mystring".constructor.prototype.asdf

Re: Math.TAU

On Wed, Jul 2, 2014 at 5:52 PM, A Matías Quezada wrote: > 1. Use Math.PI * 2 everywhere > 2. Create a TAU constant on every file > 3. Create a TAU constant on a single file and require this file from > everywhere just for this 4. Do Math.TAU = Math.PI * 2 once somewhere. It even works in node.

Loops, Let, Closures

The following ES6 code's behaviour puzzled a few developers I know. The results indicated below each snippet are run through SpiderMonkey's implementation. It is related to 13.6.3.2. I believe the wording of the current draft leaves the interaction with closures open to interpretation. for (l

Re: restrictions on let declarations

On Thu, Jan 30, 2014 at 8:27 PM, John Lenz wrote: > I don't argue that it isn't a useless "let". For the sake of argument, can you construct a non-block-scoped `if (…) …` which is actually any useful, assuming your mental model of if (…) … <==> if (…) { … } (which must be removed from teach

Re: Standardizing console APIs: Where?

On Wed, Feb 27, 2013 at 7:55 PM, François REMY wrote: >> In browsers, when logging an object, you can actually click on an arrow >> to browse through all its properties. >> Serializing the whole thing on every single console.log, when those >> happen in a loop, >> would make the debugging experien

Re: Standardizing console APIs: Where?

On Wed, Feb 27, 2013 at 5:07 PM, Brian Kardell wrote: > On 26/02/2013 23:06 , Brian Kardell wrote: >> >> 1. Does anyone else feel like we _should_ have a standard > > > I think that this thread has shown that there are interoperability issues. > Given that this is a debugging tool, you really want

Re: Standardizing console APIs: Where?

On Fri, Feb 22, 2013 at 5:31 PM, Rick Waldron wrote: > On Fri, Feb 22, 2013 at 11:13 AM, Brian Kardell wrote: >> >> Recently I read a post about Chrome adding a console.table API which >> mentioned some things in other browsers. My immediate reaction was "is this >> a new proposal for addition t

Re: Polyfill for Maps and Sets

On Thu, Jan 17, 2013 at 8:12 PM, Domenic Denicola wrote: > Dude, do you even read the spec? > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4 So this is just the wiki lacking some updates? http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets __

Re: Polyfill for Maps and Sets

On Thu, Jan 17, 2013 at 7:58 PM, Brandon Benvie wrote: > There's multiple polyfills for Map, Set, and WeakMap (WeakMap not being > fully implementable, but close). Here's one: > http://benvie.github.com/harmony-collections. This polyfill isn't exact in the same way that I described. The differenc

Polyfill for Maps and Sets

I believe it is impossible to do even a partially functional polyfill for Maps and Sets in ES5. Indeed, the only way to iterate through it is with the 'for (… of …)' construct, which is sure to break in ES5. I wish there was a way to polyfill it. Something like 'Map.prototype.getKeys' could return

Re: "var" declarations shadowing properties from Window.prototype

On Wed, Aug 15, 2012 at 8:16 AM, Boris Zbarsky wrote: > On 8/15/12 3:48 AM, Axel Rauschmayer wrote: >> >> In FF 14, I’m getting the following results (if there is an element >> whose ID is "foo"): >> >> $ "foo" in window >> false >> $ foo >> ReferenceError: foo is not defined >

Re: ES Modules: suggestions for improvement

On Tue, Jun 26, 2012 at 10:12 AM, John J Barton wrote: > As I understand it, two issues drive the need for standardization of > modules: >   1) we want one environment for all JS, >   2) to move beyond the limitations of RequireJS and CommonJS requires > parsing, and that is considered too expensi

Re: More fun with undefined

On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock wrote: > This is a different issue, but I wonder how badly the web would break if we > made undefined a reserved word.  Does anybody in JS really declare a > different local binding for undefined?  In ES5 we got away with making > undefined read-o

Re: Default operator strawman - ||| rather than ??

On Tue, Jun 12, 2012 at 10:17 PM, David Herman wrote: > On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote: > >> My point still stands. Being "undefined"-specific is arbitrary. >> CoffeeScript could have been "undefined"-specific; they were >> "undefin

Re: Default operator strawman - ||| rather than ??

On Tue, Jun 12, 2012 at 6:11 PM, Tab Atkins Jr. wrote: > On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl wrote: >> On the other hand, non-existent properties are a use-case. >> CoffeeScript provides a similar feature, but for null properties. >> >> For example, the follo

Re: Default operator strawman - ||| rather than ??

On Tue, Jun 12, 2012 at 1:56 PM, Tab Atkins Jr. wrote: > On Tue, Jun 12, 2012 at 1:37 PM, Peter van der Zee wrote: >> On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder >> wrote: >>> In the current default operator strawman[1], the operator is ??, e.g.: >>> >>> a = b ?? 5; >>> >>> is shorthand for >

Re: Digraphs *and* Unicode pretty-glyphs, for arrows, triangle, etc.

On Thu, Apr 5, 2012 at 5:00 PM, Adam Shannon wrote: > I don't see anything inherently wrong with adding some nice sugar to > ES, because the people who will be using this "math heavy" notation > will be those who are used to it. The "everyday" ecmascript programmer > probably won't touch these bec

Re: Digraphs *and* Unicode pretty-glyphs, for arrows, triangle, etc.

On Thu, Apr 5, 2012 at 7:23 AM, Brendan Eich wrote: > From http://www.scala-lang.org/node/4723 (hat tip *Corey > Farwell*‏@*frewsxcv* > >  * > > > ): > > |=>   ⇒   // implemented > <-  ←   // implemented > ->   →   // implemented > ==  ⩵ >>> >>>  ≫ > > <<   ≪ >>

Re: value objects

On Tue, Mar 20, 2012 at 2:20 PM, Andrew Paprocki wrote: > On Tue, Mar 20, 2012 at 4:27 AM, Herby Vojčík wrote: >>> >>> I understand lots of apps want "native" int64 as soon as possible > > > I would love to see IEEE754r as soon as possible. Being able to represent > certain financial calculations

Re: optional "function" keyword

From: Brendan Eich >From: Isaac Schlueter >> Yes, an identifier is required.  It would not be possible to define an >> unnamed function in this way. > > > Why not express an anonymous function, though? Definition != expression. As > usual, an expression *statement* could not start with ( and consis

Re: optional "function" keyword

On Tue, Mar 6, 2012 at 6:50 PM, Isaac Schlueter wrote: > A great many letters have been typed regarding the number of letters in the > word "function". > > What if we just made the keyword "function" entirely optional, dart-style? > > ShortNamedFunctionDeclaration :Identifier  ( FormalParameterLis

Re: What should Map iteration do?

Related: I cannot find the reason why sets and maps were harmoni'ed with classes[1]. They do support `mySet["foo"]` for `mySet.has("foo")` and `for (something of mySet)` for iteration, do they not? Classes don't have operator overloading, so using classes makes it harder to see the usual syntax fo

Native Assertion module?

(I am sorry that I mistakenly sent this only to Rick Waldron. I intended it for es-discuss.) On Mon, Feb 13, 2012 at 5:04 PM, Rick Waldron wrote: > I was wondering if a native Assertion module had ever been discussed or > proposed - I searched[1] and found nothing. If anyone can point me to > exi

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

On Sat, Jan 28, 2012 at 1:10 AM, Brendan Eich wrote: >> Tom Van Cutsem >> January 27, 2012 10:53 AM >> >> >>    Off-topic: What is the recommended style for naming modules? >>    Capitalized and camel-cased? It’s nothing I couldn’t get used to, >>    but it seems like t

Re: Block lambda is cool, its syntax isn't

On Wed, Jan 18, 2012 at 10:28 AM, Gavin Barraclough wrote: > Just a thought, has a prefix ^ been considered? > > A lambda that takes no arguments could be: > ^{ /*...*/ } > And a lambda with some arguments: > ^(x,y){ /*...*/ } > > I just find this really readable, the syntax for lambdas that take

Re: Block lambda is cool, its syntax isn't

2012/1/13 Quildreen Motta : > I have an obvious bias towards 1 because I think Unicode symbols > describe much better the underlying intentions and semantics than > their ASCII alternatives (usually), however not many people creates > mappings for these symbols on their .XCompose (or even have a co

Re: Block lambda is cool, its syntax isn't

On Thu, Jan 12, 2012 at 11:23 PM, François REMY wrote: > Am I wrong if I say there not a bigger issue with block lambda than with the > current object notation on the matter? > > I mean, does that code mean anything useful? > >   function() { >       {|a,b| a+b}; >   } > > If not (as it seems to m

Block lambda is cool, its syntax isn't

I have heard many fellow programmers say that, while block lambdas would be welcome, Ruby's |a, b| syntax is ugly. I thought I was the only one feeling this way, but since I am not, I would like to ask why the parentheses cannot be used there. { (a, b) a + b } cannot conflict with any existin

Re: Octal literals have their uses (you Unix haters skip this one)

On Thu, Jan 12, 2012 at 9:57 PM, Axel Rauschmayer wrote: > If we were willing to add octal with a clear prefix I would be fine with > that, for consistency with hex, I'd lean towards 0o<...>, but I'm open to > any suggestions that people may wish to add.  Personally I'd also like a > binary form,

Re: Octal literals have their uses (you Unix haters skip this one)

Can't we just have free competition between "0o644" and "0644"? Add the former, and we'll see which wins in real code! If "0o644" wins, and if people like Doug Crockford advocate the drop of "0644", we may then consider including this in a new version of Strict Mode. Furthermore, I'd like to wei

Re: Summary: prototypes as classes

> From: Axel Rauschmayer >> On the other hand people may find Point.new(x, y) as intuitive, as they will >> think of ruby instead of java. > > As an aside, you can see API code for the above functionality here: > - https://github.com/Gozala/selfish [Irakli, updated] > - http://dl.2ality.com/dl/20

Re: May 24-26 rough meeting notes

On Mon, May 30, 2011 at 6:55 AM, Brendan Eich wrote: > On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote: >> ... I believe that, given the fact that browsers will implement >> ES.next incrementally, we should find a way to allow graceful >> fallback, rather than version-driven c

Re: May 24-26 rough meeting notes

On Sun, May 29, 2011 at 10:00 PM, Brendan Eich wrote: > On May 29, 2011, at 12:55 PM, Thaddee Tyl wrote: > >> Don't be upset! > > Not at all, I'm simply skeptical (and saucy in saying so) about > jurisdictional fights this early in thinking creatively about cross-c

Re: May 24-26 rough meeting notes

at 6:45 AM, Thaddee Tyl wrote: > >>>>> Consensus on moving some form of versioning into Harmony.  The strawman >>>>> is a >>>>> bit light at this time, so no specifics yet. >>>> >>>> A lot of the above looks like HTML. Isn

Re: May 24-26 rough meeting notes

> Date: Sat, 28 May 2011 12:57:04 -0700 > From: Brendan Eich > http://www.mail-archive.com/es-discuss@mozilla.org/msg05005.html had the > example I was trying to reconstruct from memory at last week's meeting: > > >  // new.js inline-exanded here > >   >   > > >>> Consensus on moving some form

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

On Sat, May 7, 2011 at 6:31 PM, Peter Michaux wrote: > On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl wrote: >> I believe that David Bruant has a good point. We *need* a shorter syntax >> because we advocate the use of map/reduce, etc., which require simple >> anonymous functi

Re: es-discuss Digest, Vol 51, Issue 5

I believe that David Bruant has a good point. We *need* a shorter syntax because we advocate the use of map/reduce, etc., which require simple anonymous functions. As to why we should choose # rather than coffescript's ->, there are two points: - The # syntax is more readable. -> is perlish. It l