Re: binast/ecmascript-binary-ast

[Frankie Bagnardi]

Oh it's stage-1, cool. Thanks, I was missing the "site:" in my searches.

On Sun, Jan 14, 2018 at 9:46 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> There's been a few threads on it:
> https://www.google.com/search?q=binary+ast+site%3Aesdiscuss.org
>
> (Not saying you have to revive a previous thread, though.)
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Sun, Jan 14, 2018 at 4:35 AM, Frankie Bagnardi <f.bagna...@gmail.com>
> wrote:
> > I was thinking about sending JS programs as a binary abstract syntax
> tree,
> > and found this proposal for it:
> > https://github.com/binast/ecmascript-binary-ast
> >
> > Couldn't find an es-discuss thread on it. What do you think about it? It
> > seems like it could help to some extent with download times, and help a
> lot
> > with parse times on mobile devices.
> >
> > It'd even help with electron apps such as atom, which value startup time,
> > and node.js CLI programs which should also start up quickly.
> >
> >
> > ___
> > 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

binast/ecmascript-binary-ast

[Frankie Bagnardi]

I was thinking about sending JS programs as a binary abstract syntax tree,
and found this proposal for it:
https://github.com/binast/ecmascript-binary-ast

Couldn't find an es-discuss thread on it. What do you think about it? It
seems like it could help to some extent with download times, and help a lot
with parse times on mobile devices.

It'd even help with electron apps such as atom, which value startup time,
and node.js CLI programs which should also start up quickly.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Array.prototype.tap

[Frankie Bagnardi]

It's still extra code for mostly a debugging situation.

On Sun, Jul 16, 2017 at 6:54 PM, Gabe Johnson 
wrote:

> > This is definitely something that can be polyfilled (with different
> levels of naivety) but requires modifying built-ins which is a no-no.
>
> You can safely modify `Object.prototype` using `Symbol`.
>
> ```js
> export const tap = Symbol('tap');
>
> Object.prototype[tap] = function tap(f) {
>   f(this);
>   return this;
> }
>
> [1, 2, 3]
>   .map(n => n * 2)
>   [tap](console.log.bind(console))
>   .reduce((a, b) => a + b);
> ```
>
> No need to add a new method to `Array.prototype` and you can use it with
> any type.
>
> ___
> 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: flatMap or flatten

[Frankie Bagnardi]

I often do the `.reduce((xs, ys) => xs.concat(ys))` and I feel the need to
leave a comment explaining what it does.

+1 to this proposal.


On Fri, May 19, 2017 at 12:44 PM, Luan Nico  wrote:

> I always surprise myself finding out there's no native way to flat an
> array. I know it's easy to implement, but to increase legibility I propose
> creating one of two options (either suffice, I believe):
>
>   - `flatMap` : regular map, but flattens the array afterwards
>   - `flatten` : just call on an array and get a new flattened array
>
> Some examples usages of both:
>
> With `flatMap`:
> ```
> const numbers = [12, 35];
> const divisors = numbers.flatMap(factors);
> ```
>
> With `flatten`:
> ```
> const numbers = [12, 35];
> const divisors = numbers.map(factors).flatten();
> ```
>
> Flattening an array is converting something like `[1, [2, 3], 4]` to `[1,
> 2, 3, 4]`.
> There is also need to choose whether it's deep or shallow.
>
> I suggest adding a `flatten` shallow method, as that would be useful in
> all scenarios described.
>
> Example implementation:
>
> ```
> Array.prototype.flatten = function () {
> return [].concat.apply([], this);
> };
> ```
>
> What are your opinions about it?
>
> ___
> 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: Object.equals() and Object.clone()

[Frankie Bagnardi]

I guess it could throw if it's unable to clone something. This would
include *any* class without `Symbol.clone`. The error messages would need
to be outstanding for it to be practical. Like showing the path to the
thing that can't be cloned and the name of the constructor.


On Mon, Nov 14, 2016 at 9:01 PM, Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> I think you'd definitely need to call the constructor for classes because
> of scoped variables (e.g. scoped weakmap for private properties).
>
> I would like a way to compare simple objects like identical arrays though.
>
> On Mon, Nov 14, 2016 at 7:58 PM, Frankie Bagnardi <f.bagna...@gmail.com>
> wrote:
>
>> It's pretty hard to decide how these behave, specifically with custom
>> classes. Focusing on Object.clone...
>>
>> - with classes do you call the constructor, and with what arguments?
>> - HTMLElement and sub classes can't be constructed directly, what happens
>> with them?
>> - do you copy internal properties? this would make it hard to polyfill
>> - how does it behave with getters and setters?
>> - with regular expressions do you copy the lastIndex?
>>
>> Most of those apply to Object.equals also.
>>
>>
>>
>> On Mon, Nov 14, 2016 at 6:25 PM, Kevin Barabash <kev...@khanacademy.org>
>> wrote:
>>
>>> It would be nice if deep equality checking and deep cloning of objects
>>> was included in the standard library.  Has there been any proposals around
>>> including these in the past?
>>>
>>> – Kevin
>>>
>>>
>>> ___
>>> 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
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.equals() and Object.clone()

[Frankie Bagnardi]

It's pretty hard to decide how these behave, specifically with custom
classes. Focusing on Object.clone...

- with classes do you call the constructor, and with what arguments?
- HTMLElement and sub classes can't be constructed directly, what happens
with them?
- do you copy internal properties? this would make it hard to polyfill
- how does it behave with getters and setters?
- with regular expressions do you copy the lastIndex?

Most of those apply to Object.equals also.



On Mon, Nov 14, 2016 at 6:25 PM, Kevin Barabash 
wrote:

> It would be nice if deep equality checking and deep cloning of objects was
> included in the standard library.  Has there been any proposals around
> including these in the past?
>
> – Kevin
>
>
> ___
> 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: Standardize ES Worker

[Frankie Bagnardi]

It doesn't really need to clone anything, you just create a promise on each
side, on top of the normal events. The way you'd implement this currently
is a token that gets passed to the worker with the request payload, and
gets sent back with the response payload.

It'd just be nice to save some work for a common use case, and require less
cooperation between the worker and main code.


On Thu, Oct 27, 2016 at 6:57 AM, Boris Zbarsky  wrote:

> On 10/27/16 9:48 AM, Michał Wadas wrote:
>
>> Currently we put emphasis on request-response model - we request
>> something from function (returning Promise/taking callback) and we wait
>> for single return value. Workers are different beasts - they can emit
>> messages on their own and don't have to emit ANY messages on completion.
>>
>
> Right.  The point of workers in the web platform is to do computation in a
> separate context.  The computation need not be communicated back to the
> spawning page, because workers can do their own I/O.
>
> // main.js
>> const worker = new Worker('worker.js');
>> worker.request('ajaxCall', {url: 'example.com '});
>> // return Promise resolving to Response object
>> worker.request('undefinedMethod'); // return rejected Promise
>>
>> // worker.js
>>
>> self.on('ajaxCall', (data)=>{ return Promise.resolve(new Response); });
>>
>
> Workers in the web platform have a shared-nothing model.  The above
> example seems to assume that the Response and the Promise are either shared
> across the main script and the worker or auto-cloned at the boundary, right?
>
> -Boris
>
> ___
> 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: improve import syntax

[Frankie Bagnardi]

Oh I see your point. Still extremely unlikely the syntax will change.

On Sun, Jul 31, 2016 at 11:56 AM, Kris Siegel <krissie...@gmail.com> wrote:

> The syntax could stay the same while adding the other way as well. Yes it
> adds a complication but I don't know that auto complete friendliness was
> considered when adding the original syntax.
>
> You can't really say the editor is the problem because there are cases in
> which an editor can't realistically guess where the imported item will be
> coming from for an auto complete but with the suggested changes it could as
> Ali suggests.
>
> I would say making the syntax more auto complete friendly should be a
> topic to explore. Makes it easier for developers (which should be the goal
> of almost all standard changes).
>
> On Jul 31, 2016 11:50 AM, "Frankie Bagnardi" <f.bagna...@gmail.com> wrote:
>
>> It's too late to change the import syntax. The problem is your editor,
>> not the syntax. Over time more editors will support import syntax, either
>> directly or with plugins. For now, you just have to wait.
>>
>> On Sun, Jul 31, 2016 at 3:38 AM, Ali Ghanavatian <
>> ghanavatian@gmail.com> wrote:
>>
>>> Hello there,
>>> I am writing to express weak point currently affects the import syntax.
>>> As you know current syntax is not editor (specially auto-complete) friendly
>>> as editor would not have any clue about what is about to be imported and
>>> from where.
>>>
>>> import { ComponentName } from 'path/to/module-file';
>>>
>>>
>>> My suggestion is to add support for this syntax:
>>>
>>> from 'path/to/module-file' import { ComponentName };
>>>
>>>
>>> Which makes auto-completion and development easier.
>>>
>>> I think it deserves a proposal, but it's my first idea. I really
>>> appreciate any sort of guidance and suggestion about this issue and how to
>>> put it into the standard.
>>>
>>> --
>>>  Sincerely
>>> A. Ghanavatian <http://www.google.com/profiles/ghanavatian.ali>
>>>
>>> ___
>>> 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
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: improve import syntax

[Frankie Bagnardi]

It's too late to change the import syntax. The problem is your editor, not
the syntax. Over time more editors will support import syntax, either
directly or with plugins. For now, you just have to wait.

On Sun, Jul 31, 2016 at 3:38 AM, Ali Ghanavatian 
wrote:

> Hello there,
> I am writing to express weak point currently affects the import syntax. As
> you know current syntax is not editor (specially auto-complete) friendly as
> editor would not have any clue about what is about to be imported and from
> where.
>
> import { ComponentName } from 'path/to/module-file';
>
>
> My suggestion is to add support for this syntax:
>
> from 'path/to/module-file' import { ComponentName };
>
>
> Which makes auto-completion and development easier.
>
> I think it deserves a proposal, but it's my first idea. I really
> appreciate any sort of guidance and suggestion about this issue and how to
> put it into the standard.
>
> --
>  Sincerely
> A. Ghanavatian 
>
> ___
> 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: JavaScript Language feature Idea

[Frankie Bagnardi]

That would break backward compatibility;

```js
var a = ['a'];
a['-1'] = 'test';
Object.keys(a) // ['0', '-1']
```


On Sun, Apr 17, 2016 at 11:53 AM, Biju  wrote:

> We cam make this simpler, in Javascript Array.slice() already accept
> negative index.
> Developers from Javascript and other languages are familiar with
> negative value for index parameter.
> So why cant we make array accept negative index.
>
> in comparison with Bob Myers' proposal
>
> > ```
> > [1,2,3](-1)
> > ```
>
> will become
>
> ```
>  [1,2,3][-1]
> ```
>
> This will also allow us to set value using negative index,
> example
>
> var array_data = [1, 2, 3, 4];
> array_data[-1] = 5;
> array_data[-3] = 6;
>
> // now array_data is [1, 6, 3, 5]
> ___
> 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: Re[2]: Operators overriding

[Frankie Bagnardi]

Generally letting proxies do more things is a good thing, but what would be
the cost in optimizing JITs? It seems like e.g. making `a + b` or `a | 0`
more flexible would also make them slower.  Is this incorrect?

On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH  wrote:

> I dislike this proposal.
> 1 It is not very good to limit overrideable operators to value classes.
> 2 It is not very good to have a lot of custom operators, it will break
> code readability and will allow more efficient obfuscration.
> 3 I think that most of binary non-assigning operators must return a new
> object and thats' why they should be not object methods, but the methods
> taking 2 (or more if chained!) objects and return the result usually of
> same type.
> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere <
> sander...@gmail.com>:
>
>
> IMO, operator overloading is important and different enough to warrant a
> separate syntax.
>
> But the difficulty isn't in defining the operator, but in the ambiguous
> cases. Like what to do when there are 2 different types, how to make sure
> certain relations will stay correct, ...
>
> There's a nice presentation from Brendan Eich here:
> http://www.slideshare.net/BrendanEich/value-objects2
>
> Regards,
> Sander
>
> 2015-12-18 21:24 GMT+01:00 KOLANICH  >:
>
> Hello. What do you think about overriding operators using proxies?
>
> For example
> function A(r=""){
> this.rep=r;
> return new Proxy(this,{operators:{"+":function(a,b){return new
> A(a.rep+"+"+b.rep);}}});
> }
> let a=new A("a"), b=new A("b");
> let c=a+b;
> console.log(c.rep);//a+b
>
> ___
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[Frankie Bagnardi]

Decorators can be both used to wrap things and to annotate them. For
example, here we're setting a flag with the `web.method` function which is
used by by this fictional 'web' framework. The others are used as
middleware that modify the function arguments at each step.

```js
export default
@web.method('post')
@web.parsesJSON()
@web.expectsBody({
  emailAddress: String, password: String,
})
function handleLogIn(req, res, body){
  // ...
}
```

In this example we have a React component that's just a simple function. We
want to wrap it with a high order component.

```js
@providesSomething()
function MyComponent({something}){
  // ...
}
```

Here we're using dependency injection:

```js
@di.provide(Calculator)
function add(calc, a, b){
  return calc.add(a, b);
}

add(1, 2) === 3
```

I'm not completely sold on if these are good ideas. It might be more
confusing than it's worth.


On Tue, Oct 20, 2015 at 7:23 AM, Eli Perelman  wrote:

> More drive-bys.
>
> I could see decorators as a nice way to define "functional" behavior for
> generic functions:
>
> @curried
> var add = (a, b) => a + b;
>
> @memoize
> var fetch = (url) => /* logic */;
>
> Eli Perelman
>
> On Tue, Oct 20, 2015 at 8:42 AM, Kevin Smith  wrote:
>
>> I would just say that it is odd in the extreme that a group of
>>> world-leading language designers would just throw in the towel when
>>> confronted with a pretty small roadbump, instead of figuring out ways to
>>> solve it.
>>>
>>
>> Another drive-by...
>>
>> The trick is introducing new features without exploding the number of
>> rules which must be remembered in order to use that feature.
>>
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Return value of forEach

[Frankie Bagnardi]

That'd be a compatibility break.

If we end up getting :: though:

```js
function logEach(){
  this.forEach((x) => console.log(x));
  return this;
}


const a = [1, 2, 3]
  .map(square)
  ::logEach()
  .map(plus1)
  .reduce(add);
```

You could make that a global variable so you can sprinkle it around your
code in development.

Having some developer tools in the language would be nice though. I don't
even think console.log is in the spec. A global like Debug.logThis for
example would be a more general ::-able.


On Fri, Oct 16, 2015 at 5:32 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> ```js
> const a = [1, 2, 3]
>   .map(square)
>   .map(x => console.log(x) || x )
>   .map(plus1)
>   .reduce(add);
> ```
>
> Regards
>
>
> On Fri, Oct 16, 2015 at 10:13 AM, Niloy Mondal 
> wrote:
>
>> Currently, `Array.prototype.forEach` returns `undefined`. It would be more
>> useful if it returns the array itself.
>>
>> Say I have written some code like this...
>>
>> ```js
>> const a = [1, 2, 3]
>>   .map(square)
>>   .map(plus1)
>>   .reduce(add);
>> ```
>>
>> For some reason, I am not getting the expected output. For debugging, I
>> would
>> like the print the values after each step. My first initial reaction is to
>> put a `forEach` step in between and print the values like so...
>>
>> ```js
>> const a = [1, 2, 3]
>>   .map(square)
>>   .forEach(x => console.log(x))
>>   .map(plus1)
>>   .reduce(add);
>> ```
>>
>> Unfortunately, this does not work as `forEach` returns `undefined`. I now
>> have
>> to comment out all the code below it. Having the _plug and play_
>> behaviour for
>> `forEach` would be very convenient.
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Frankie Bagnardi]

I don't think there's much value in this. Also sort is a bad example
because it'd look like this, and there's no nifty shortcut answer to it.

```js
names.sort((a, b) => a < b ? 1 : a > b ? -1 : 0);
```

In most cases you save a couple characters, but you can just use
x/y/a/b/f/g/n/xs/xss for variable names in arrow functions instead of the
$0 (which would likely be \0 in js).



On Sun, Oct 11, 2015 at 3:26 PM, Caitlin Potter 
wrote:

> In the case of sorting, are arrow functions not good enough? Or are we
> really asking for full continuation support
>
> On Oct 11, 2015, at 5:51 PM, Alexander Jones  wrote:
>
> IMO this is a good idea. When it's abundantly clear from context, I've
> already been naming my arrow function params _ if singular, and _1, _2 etc
> if several. As always, picking some punctuation straight from the scarce
> and sacred set of remaining ASCII symbols is going to be tricky. (If only
> we could just go APL on this!)
>
> On 11 October 2015 at 16:45, Mohsen Azimi  wrote:
>
>> Is it possible to extend JavaScript syntax to support Swift style block
>> syntax[1]?
>>
>> In Swift it's possible to omit return keyword
>> ```
>>
>>1. reversed = names.sort( { s1, s2 in s1 > s2 } )
>>
>> ```
>>
>> or omit argument declaration like this:
>>
>> ```
>>
>>1. reversed = names.sort( { $0 > $1 } )
>>
>> ```
>>
>> or apply an operator to arguments of a function
>>
>> ```
>>
>>1. reversed = names.sort(>)
>>
>> ```
>> We have the first feature in ES2015 already:
>>
>> ```
>> let sorted = names.sort((a, b)=> a > b);
>> ```
>>
>> But for omitting argument declaration we need to find an alternative to
>> $0, $1... since those are valid variable names in JS. Maybe we can use #0,
>> #1... instead.
>>
>> This is very useful for functional programming aspect of JS. For example
>> in a filter function:
>>
>> ```
>> let passed = objs.filter(#0.passed)
>> ```
>>
>>
>>
>>
>> [1][
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html
>> ]
>>
>> ___
>> 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
>
>
> ___
> 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

import {x with x() as y}

[Frankie Bagnardi]

There are often situations where the export of a module is only needed as
an argument to another function, or for its return value.

```js
import _temp1 from 'debug';
let debug = _temp1('foo');

import {readFile as _temp2} from 'fs';
let readFile = promisify(_temp2);

import _temp3, {Router} from 'express';
let app = _temp3();
```

This juggling could be avoided by allowing usage of the exports without
binding them locally. Something like this:

```js
import {default with default('foo') as debug} from 'debug';

import  {readFile with promisify(readFile) as readFile} from 'fs';

import {Router, default with default() as app} from 'express';
```

Has this been brought up before? Thoughts?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: self functions

[Frankie Bagnardi]

Aside from returning `this` you're suggesting an alternate syntax for arrow
functions? I don't see any value here.

More importantly, the syntax is ambiguous for unnamed functions.

```js
// already valid syntax
var self = function self(){};
```



On Mon, Jul 27, 2015 at 7:06 PM, Bucaran jbuca...@me.com wrote:

 Add a `self` decorator to functions that makes them return `this` by
 default.

 export function self myMethod () {
 // return this by default
 }

 This decorator could be used to make any function bound to the current
 scope `this` as well so:

 func(function self () { // this is bound to my dad’s scope
 })

 Would be roughly equivalent to:

 func(() = { // this is bound to my dad’s scope })

 Although I personally would favor the arrow function syntax, the `self`
 decorator could be
 used to optimize binding generators, so instead of:

 func(function* () { }.bind(this))

 One could write:

 func(function self* () { })

 Similary it could be used in promise handlers, so instead of:

 new Promise(function (resolve, reject) { }.bind(this))

 One could write:

 new Promise(function self (resolve, reject) { })

 It would be even sweeter if you didn’t need to specify the keyword
 function when writing `self` functions:

 new Promise(self (resolve, reject) { })
 ___
 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: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Frankie Bagnardi]

In 10 years, we probably won't be using tools for the modules added in
ES2015, but we might be using them for the changes made in ES2020.

On Thu, Apr 23, 2015 at 7:24 AM, Eric B neuros...@gmail.com wrote:

 So just to clarify, when browsers support es6 modules we will still need
 some extra library to bundle the modules?  This would mean es6 modules are
 only a syntactical addition and not something functional?

 On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi f.bagna...@gmail.com
 wrote:

 Matthew, there are already tools for es6 modules + bundling (e.g. babel +
 webpack), or converting es6 modules to AMD (e.g. babel
 https://babeljs.io/docs/usage/modules/).



 On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com
 wrote:


 Can you clarify what you mean about bundling? Unless I've missed
 something, the ES6 module system does not have a story for bundling at all.
 Of course formats can be invented in userland but I'm not sure that they
 are any easier to implement than say AMD's.  I might have missed something
 though, looking forward to your reply.

 ___
 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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Frankie Bagnardi]

Matthew, there are already tools for es6 modules + bundling (e.g. babel +
webpack), or converting es6 modules to AMD (e.g. babel
https://babeljs.io/docs/usage/modules/).



On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com
wrote:


 Can you clarify what you mean about bundling? Unless I've missed
 something, the ES6 module system does not have a story for bundling at all.
 Of course formats can be invented in userland but I'm not sure that they
 are any easier to implement than say AMD's.  I might have missed something
 though, looking forward to your reply.

 ___
 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: Should const be favored over let?

[Frankie Bagnardi]

I've switched to let/const completely.  The gain of using const isn't
performance (you can statically analyze whether any non-global is
potentially assigned to).  The gain from const is that it's very very easy
for a human to statically analyze.

If I see a let binding, I know I need to be a bit more careful with editing
that piece of code.

I originally thought this'd be a terrible idea, but it's been working great
for me.


On Thu, Apr 16, 2015 at 10:53 PM, Glen Huang curvedm...@gmail.com wrote:

 I've completely replaced var with let in my es 2015 code, but I
 noticed most variables I introduced never change.

 Should I replace them with const? Will there be any performance gain for
 most browsers? If so, should such performance gain be considered micro
 optimization?
 ___
 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: forward-incompatible Function.prototype.toString requirement

[Frankie Bagnardi]

The part that sticks out to me is... toString on functions currently throws
a syntax error when eval'd for non-named functions.  Tested in chrome:

var f = function(){ return 1 };eval(f.toString()); // SyntaxError
// becausefunction(){ return 1 }; // SyntaxError
// but, force an expression: eval(( + f.toString() + )) //
essentially clones f

​
This... is confusing in my opinion.


On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg rossb...@google.com
wrote:

 On 16 April 2015 at 11:34, Michael Ficarra mfica...@shapesecurity.com
 wrote:

 ES2015 section 19.2.3.5 (Function.prototype.toString) places four
 restrictions on the output of Function.prototype.toString, one of which is

 If the implementation cannot produce a source code string that meets
 these criteria then it must return a string for which *eval* will throw
 a *SyntaxError* exception.


 What is a SyntaxError today may not be a SyntaxError tomorrow. How can an
 implementation return a string that will satisfy this requirement in the
 future when the language has added new syntax? Does the committee have a
 SyntaxError recommendation that can be added as a non-normative note to
 that section?


 In the (probably unlikely) case that the language changed that way, and an
 affected implementation adopted that change, then it would simply have to
 change its toString implementation accordingly at that point. I don't see a
 problem there.

 /Andreas


 ___
 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: forward-incompatible Function.prototype.toString requirement

[Frankie Bagnardi]

I just meant that it seems confusing that it can both produce a
FunctionExpression
and return a string for which eval will throw a SyntaxError exception.

I didn't mean to highjack this thread; the concern in the original email is
noteworthy.  There should be recommended syntaxes which future versions of
the spec agree not to break, including current browser implementations.
This gives any future engines, or modifications to current engines a
clearly defined acceptable way to format these strings.

This also gives libraries which parse functions at runtime (despite how
good of an idea this is) quick bail cases without using eval.  Examples of
this are angular and require.js.



On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller erig...@google.com wrote:



 On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg rossb...@google.com
 wrote:

 On 16 April 2015 at 14:34, Frankie Bagnardi f.bagna...@gmail.com wrote:

 The part that sticks out to me is... toString on functions currently
 throws a syntax error when eval'd for non-named functions.  Tested in
 chrome:

 var f = function(){ return 1 };eval(f.toString()); // SyntaxError
 // becausefunction(){ return 1 }; // SyntaxError
 // but, force an expression: eval(( + f.toString() + )) // essentially 
 clones f

 ​
 This... is confusing in my opinion.


 Yeah, the spec says:

 The string representation must have the syntax of a FunctionDeclaration
 FunctionExpression, GeneratorDeclaration, GeneratorExpression,
 ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition, or
 GeneratorMethod depending upon the actual characteristics of the object.

 which is weird. First, it doesn't really make sense, because whether
 something originates from a declaration vs expression isn't a
 characteristic of the object. Second, making it return different
 syntactic classes in different cases is not particularly useful for your
 case.

 But then again, using the result of f.toString as input to eval is A REAL
 BAD IDEA anyway; toString should only be used for diagnostics, not
 programmatically, because that is meaningless in general. So I personally
 don't mind the friction.


 Disagree. The purpose of this change in toString spec from ES5 is
 primarily to support pass-by-copy closed functions. The intent was that it
 always work to evaluate them as expressions, i.e., with the surrounding
 parens.

 http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
 http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#there





 /Andreas





 On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg rossb...@google.com
 wrote:

 On 16 April 2015 at 11:34, Michael Ficarra mfica...@shapesecurity.com
 wrote:

 ES2015 section 19.2.3.5 (Function.prototype.toString) places four
 restrictions on the output of Function.prototype.toString, one of which is

 If the implementation cannot produce a source code string that meets
 these criteria then it must return a string for which *eval* will
 throw a *SyntaxError* exception.


 What is a SyntaxError today may not be a SyntaxError tomorrow. How can
 an implementation return a string that will satisfy this requirement in 
 the
 future when the language has added new syntax? Does the committee have a
 SyntaxError recommendation that can be added as a non-normative note to
 that section?


 In the (probably unlikely) case that the language changed that way, and
 an affected implementation adopted that change, then it would simply have
 to change its toString implementation accordingly at that point. I don't
 see a problem there.

 /Andreas


 ___
 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




 --
 Cheers,
 --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `of` operator ES7 proposal from Ian Bicking

[Frankie Bagnardi]

First, you shouldn’t assume this would be based on the Symbol.iterator
protocol.

Would Object.create(null, {[Symbol.iterator]: value: ...}) work as it does
in for..of?

It seems like the main problem would be infinite sequences. That means
either infinite loops (ugh), or the language/user setting an arbitrary
number of max values to check (ew).

If I do have an arbitrary iterable, I need to easily create something I can
pass to for..of with if (x of fn(xs)) where fn is provided by ecmascript.
​


On Mon, Mar 30, 2015 at 12:02 PM, Brendan Eich bren...@mozilla.org wrote:

 Michał Wadas wrote:

 First possible problem - of used in if statement can put iterator in
 unexpected state or result in arbitrary side effects.


 What iterator?

 First, you shouldn't assume this would be based on the Symbol.iterator
 protocol. I wrote something like @@hasInstance for instanceof was the
 precedent to follow.

 Second, the iteration protocol would require exhaustively searching for
 values. Side effects of iteration are the least worry!

 Finally, even if the iteration protocol were used, there would be no
 shared/reused iterator. You get a fresh one from well-implemented iterables.


 /be
 ___
 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: Cancellation architectural observations

[Frankie Bagnardi]

I don't think this has been brought up, but isn't what we're doing here
bubbling an event?  Would it make sense to generalize this to a simple
event bubbling system?

function cancelableGet(url){
  const xhr = new XMLHttpRequest();
  return new Promise(function(resolve, reject){
xhr.open('get', url);
xhr

this.on('cancel', reason = {
  xhr.abort();
  reject(new CanceldRequest(reason));

  // if we wanted to pass it upwards
  this.emit('cancel', reason);
});
  });

}

cancelableGet('/foo')
.then(...)
.emit('cancel');

​

Our listener would be unbound as soon as the promise in cancelableGet settled.


This also allows for non-overlapping names for events (Symbol should be
permitted), where there may be multiple cancelable things in the chain.

It also allows additional metadata, or different event names when 'cancel'
can mean multiple things.  For example, a process.  Do we send sigint or
sigkill to cancel it?

Thoughts?



On Sun, Mar 29, 2015 at 8:56 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 OK, just for record sake, I'v ecreated a working example of what I
 previously meant.
 https://gist.github.com/WebReflection/a015c9c02ff2482d327e

 Here a basic example (something that will reject on timeout)
 ```js

 // will be resolvednew Promise(function ($res, $rej, ifCanceled) {
   var internal = setTimeout($rej, 1000);
   ifCanceled(function () {
 clearTimeout(internal);
   });
 })// will be resolved without executing
 .then(
   function () {
 console.log('on time');
   },
   function () {
 console.log('error');
   }
 )
 .cancel()// will simply execute and resolve
 .then(function () {
   console.log('no time');
 });

 ```

 The idea is that a Promise is cancelable **only** if a function that
 defines how to cancel is provided, otherwise there's no cancel-ability,
 it's a regular Promise, and nothing is exported.

 This still grants internal private/hidden cancelability through a
 resolution or rejection but it also gives the ability to expose a
 `.cancel()` to the outher world.

 There's no forever pending problem because all Promises involved in the
 chain will be silently resolved.
 The code might be a bit convolute but it was mainly to provide a
 playground and I don't see any real violation of the Promises principles.

 The presence of `cancel` and its ability is a contract between the Promise
 creator/provider and the external world.

 Best Regards



 On Fri, Mar 27, 2015 at 5:43 PM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

 following up from this
 https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , and
 most likely late to the party.

 How about cancel-ability done this way ?

 ```js

 var p = new Promise(function (res, rej, cancel) {
   // resolved in 1 second via random value
   var t = setTimeout(res, 1000, Math.random());
   // if meant to be canceled
   // we define internally what to do
   cancel(function () {
 clearTimeout(t);
   });
 });

 // whenever/if needed
 p.cancel().then(...);
 ```

 The exposed cancel-ability is arbitrary provided internally so that if
 missing, an error is thrown while if provided it sets the internal state of
 the promise as `canceled` in case it's different from `resolved` or
 `rejected`

 It gives the ability to react, if a `then` is attached, or the ability to
 ignore, if nothing happens to the returned, non cancel-able, Promise.

 This avoids exposing to the outer world what happens inside the Promise
 and provides arbitrary ability to cancel one.

 A cancel-able Promise is one that defined such behavior, which by default
 is throwing if that's not defined internally.
 This would solve already many cases I have in mind, via users, or
 UserAgent, and legitimately behind the scene without any need to expose any
 internal logic.

 How to resolve or throw other attached promises? Well,
 `p.cancel().then()` resolves, while `p.cancel().throw()` does not.
 `p.cancel()`, without then or throw would simply throw away pending
 promises as explicit `ignore` intent.

 How bad does it look and what am I screwing up in here in terms of
 Promises philosophy?

 Best Regards







 On Wed, Mar 4, 2015 at 8:01 PM, Ron Buckton ron.buck...@microsoft.com
 wrote:

  new Promise(resolve = doLater(resolve, cts.token)).then(handleResult);
  setImmediate(() = cts.cancel());

 
  In this scenario cancel would be called right after the resolve method
  is called, but before handlerResult is called. For this to work with a
  cancellation token you would need to pass the token to every step in
  the chain to both stop work being done and to ignore the
  result/prevent a handler from being called. Wouldn't it be better if
  the promise chain took care of this for the programmer?

 I can be convinced that CancellationToken registrations should be
 invoked asynchronously, though I wonder if then
 CancellationTokenSource#cancel should return a Promise to observe any
 errors that occur.

 Ron
 

Re: Cancelable promises

[Frankie Bagnardi]

My understanding was that it'd look like this:

// presumably standard
class CancelReason extends Error {}

// Promise.cancelable? third party library?
function cancelable(p, onCancel){
  // todo: refactor into utility function allowing: return
cancelable(resultPromise, () = {xhr.abort()})
  var doCancel;
  var cancelPromise = new Promise((resolve, reject) = {
doCancel = reason = {
  reject(new CancelReason(reason));
  return raced;
};
  });

  var raced = Promise.race([p, cancelPromise])
  .catch(reason = {
if (reason instanceof CancelReason) {
onCancel();
}
return Promise.reject(reason);
  });

  raced.cancel = doCancel;
  return raced;
}

function fetchAsync(url) {
  var resultPromise = new Promise((resolve, reject) = {
xhr.open(GET, url, /*async:*/ true);
xhr.onload = event = resolve(xhr.responseText);
xhr.onerror = event = reject(xhr.statusText);
xhr.send(null);
  });

  return cancelable(resultPromise, () = { xhr.abort() });
}

fetchAsync(...).then(...); // as expected
fetchAsync(...).cancel('reason').catch(...); // .catch gets the
CancelReason, and xhr is aborted
fetchAsync(...).then(...).cancel(); // TypeError .cancel is undefined

And that cancel wouldn't automatically propagate in any way; but it is a
simple callback, so can be passed around as desired.



On Fri, Feb 27, 2015 at 9:37 PM, Ron Buckton rbuck...@chronicles.org
wrote:

  AsyncJS (http://github.com/rbuckton/asyncjs) uses a separate abstraction
 for cancellation based on the .NET
 CancellationTokenSource/CancellationToken types. You can find more
 information about this abstraction in the MSDN documentation here:
 https://msdn.microsoft.com/en-us/library/dd997364(v=vs.110).aspx

 Ron
  --
 From: John Lenz concavel...@gmail.com
 Sent: ‎2/‎27/‎2015 8:01 PM
 To: Andrea Giammarchi andrea.giammar...@gmail.com
 Cc: public-script-co...@w3.org; es-discuss es-discuss@mozilla.org
 Subject: Re: Cancelable promises



 On Fri, Feb 27, 2015 at 7:49 PM, John Lenz concavel...@gmail.com wrote:

 Closure Library's promise implementation supports cancel:


 https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502

  A promise is cancelled only if all the child promises are also
 cancelled.


  I did not say that correctly, a parent promise can be cancelled by a
 child it is the only child or all the children cancel.  A parent can
 alway cancel its children (to the children this is simply reject).  It
 does add a significant amount of complexity to the promise implementation
 but it is for the most part contained there.

  I don't believe that cancel can be added after the fact and an
 alternative (subclass or otherwise) is needed.



 On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

  AFAIK bluebird did:

 https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise

  But I agree once you've made Promises more complex than events ( xhr
 in this case ) nobody wins :-/

  Although, specially for fetch or anything network related, there
 **must** be a way to bloody cancel that!

  right?


 On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith zenpars...@gmail.com
 wrote:

 The discussion on that github issue surrounding promise subclassing
 makes my head spin, especially when it comes to working out how cancelation
 is supposed to flow through a graph of promise dependencies.  We should be
 wary of adding complexity to the core.

 The simple way to view the situation is to say that promises are simply
 transparent containers for asynchronous values. Control capabilities should
 therefore be represented by a separate abstraction. This will help keep
 complexity at the edges.

 Has any library experimented with the cancelation token approach yet?
  On Feb 27, 2015 1:46 AM, Anne van Kesteren ann...@annevk.nl wrote:

 As a heads up, there's some debate around the fetch() API how exactly
 request termination should work and how that affects promises:

   https://github.com/slightlyoff/ServiceWorker/issues/625

 The WebRTC WG has also been discussing canceling in the context of
 terminating a request for permission from the user. I think they
 decided to postpone for now until there's a bit more progress on what
 cancelable promises means, but I would not expect everyone to wait
 forever.


 --
 https://annevankesteren.nl/
 ___
 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



 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 

Re: Should `use strict` be a valid strict pragma?

[Frankie Bagnardi]

I think any issues with that are imagined.  Languages have rules, and of
the people who both know what 'use strict' does and are using es6 syntax,
they're very unlikely to make the mistake.

I don't see people using template literals for arbitrary strings... it
could happen but it probably won't.  Mathias makes a good point also, it's
not strings that equal the string 'use strict', it's exactly two possible
arrangements of characters.



On Thu, Feb 5, 2015 at 6:12 AM, Andy Earnshaw andyearns...@gmail.com
wrote:

 I think you're missing the point Leon is trying to make.  He's saying
 that, in ES 6 we have a new way to write strings.  In some ways, these more
 powerful strings may condition some people to use ` as their main string
 delimiter.  An unsuspecting person may liken this to PHP's double quotes vs
 single quotes, thinking that the only difference is that you can use
 `${variable}` in strings that are delimited with backticks, but other than
 that everything is the same.  When they write this in their code:

 ```
 `use strict`;
 ```

 They may introduce bugs by writing non-strict code that doesn't throw when
 it should.  Adding it to the spec wouldn't be difficult and it would avoid
 any potential confusion or difficult-to-debug issues.  It's definitely
 easier than educating people, IMO.

 On Thu, Feb 5, 2015 at 10:56 AM, Mathias Bynens math...@qiwi.be wrote:


  On 5 Feb 2015, at 11:04, Leon Arnott leonarn...@gmail.com wrote:
 
  Well, that isn't quite the full story - if it were just a case of
 pragmas having to use something, anything, that could pass ES3 engines,
 then there wouldn't necessarily be two otherwise-redundant forms of the
 syntax - `use strict` and `'use strict'`. The reason those exist is to
 save the author remembering which string delimiter to use - it mirrors the
 string literal syntax exactly.

 If that were the case, then e.g.
 `'\x75\x73\x65\x20\x73\x74\x72\x69\x63\x74'` would trigger strict mode. (It
 doesn’t, and that’s a good thing.)
 ___
 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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript 2015?

[Frankie Bagnardi]

 [...] asking Oracle [...]

If they both read it and reply (you have a decent chance of getting one or
the other, both is unlikely).




On Sat, Jan 24, 2015 at 3:47 PM, Isiah Meadows impinb...@gmail.com wrote:

 @all

 Should we rename this list to es-bikeshed? Seems to fit with the theme
 here. ;)

 In all reality, I'm strongly considering asking Oracle about the specific
 enforcement status of the JavaScript trademark. If (and when) I do, I'll
 forward as much information as I can here.

 ___
 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: A new ES6 draft is available

[Frankie Bagnardi]

arguments.new.target makes more sense to me.

If we do want to move towards keyword.identifier being a normal occurance,
then I think new.target is perfectly reasonable.  I'm all for that, and it
makes the job of tooling a lot simpler where it's used.

In the current draft, is new[target] a syntax error, or equivalent to
new.target?

On Sat, Jan 17, 2015 at 12:20 PM, Kevin Smith zenpars...@gmail.com wrote:


  Once this idea is in play, It also seems like a good solution for some
 other extensions we have grapple with.  Consider, for example:
  function.callee
  function.arguments
  module.name

 or yield.input

 ___
 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: A new ES6 draft is available

[Frankie Bagnardi]

I'm also expecting a lot of questions about 'what is this new.target thing
in this code?', 'is new a variable?', 'where does it come from?', 'isn't
new an operator?', etc.

if (this instanceof MyDate) ...

... is clearer, but I guess it needs to be disallowed because of the other
rules.

On Fri, Jan 16, 2015 at 1:29 PM, Brendan Eich bren...@mozilla.org wrote:

 Gotta agree new.target is nicer to read and write!

 /be

 Allen Wirfs-Brock wrote:

 err,
  try {
   let thisValue = this;  //can't reference 'this' prior to
 'super()' in a [[Construct]] call of a derived function
  } catch (e} {
 calledAsFunction = false  //no let here
 }

  ___
 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: (x) = {foo: bar}

[Frankie Bagnardi]

That's good news, thanks for the strawman link.  Is it correct to assume
this with that proposal?

var f = (x) = (y) = {x, y};
f(1)(2) // = {x: 1, y: 2};



On Mon, Jan 5, 2015 at 12:54 PM, Brendan Eich bren...@mozilla.org wrote:

 Caitlin Potter wrote:

 The strawman changes to the grammar are still ambiguous :(

 `() = {}` - noop or Object or SyntaxError? If SyntaxError, ...why?


 No, the strawman addresses this: An empty pair of braces |*{}*| other
 than at start of /Statement/ is an /ObjectLiteral/. The grammar is
 unambiguous. Notice the meta-? in the first production RHS below, and the
 non-empty-producing nature of the second:

 Block:
 { UnlabeledStatementFirstList? }
 { WellLabeledStatement StatementList? }

 UnlabeledStatementFirstList:
 UnlabeledStatement
 UnlabeledStatementFirstList Statement


 The final piece of the puzzle is here:

 We retain the |[lookahead ∉ {*{*, *function*}]| restriction in
 /ExpressionStatement/. At the start of a statement, |*{*| can be the start
 of a block only, never an object literal.

  I think hacking around this would not get rid of the footgun, but would
 just make it more complicated to understand the footgun, personally.


 You mean replace the footgun with a smaller one, maybe one so small it
 doesn't matter. Saying that the proposal doesn't get rid of the footgun
 means it still remains impossible to write x = {p: x} and not get what
 Frankie and others want: an arrow returning an object. But the proposal
 does fix that footgun.

 How often do you really want an empty object instead of a block with no
 statements?

 /be

 ___
 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

(x) = {foo: bar}

[Frankie Bagnardi]

let f = (x) = {foo: bar};

In the implementations I checked, this is actually allowed, but it's parsed
as a label instead of what you may expect at first glance (an object).

Is there any reason this is allowed?  If there's no reason other than to
match function(){}, this should be a syntax error, in my opinion.

A potentially easier and wider reaching solution here would be to restrict
labels in strict mode to demand a possible break/continue, else it's a
syntax error.  The only area I'd be concerned about compatibility is low
level generated JavaScript.

Thoughts?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: class properties inheritance

[Frankie Bagnardi]

That's why you call super(); as the first line in the constructor.

On Sun, Dec 28, 2014 at 2:42 PM, Антон Шувалов an...@shuvalov.info wrote:

 Hi, guys! I'm confused with class properties. With prototype chains I can
 setup kinda default values which being replaced by values from children.
 But replacing become hard to work with classes. For example, we have simple
 module, some backbone view:

 ```js
 class BaseView extends Backbone.View {
   constructor() {
 this.tagName = 'div';
 super(); // create element from this.tagName value
   }
 }
 ```

 And now we create inherited view:

 ```js
 class Span extends BaseView {
   constructor() {
 this.tagName = 'span'
 super();
   }
 }
 ```

 But all `this` variables will be replaced by parent, not by child. It's
 kinda weird. Another example with prototype chains works fine:

 ```js
 var BaseView = Backbone.View.extends({
   tagName: 'div'
 })
 ```

 ```js
 var Span = Backbone.View.extends({
   tagName: 'span'
 });
 ```

 How I can do similar things with es6 classes? Sorry if this question is
 already discussed.
 ___
 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: Define static properties and prototype properties with the class syntax

[Frankie Bagnardi]

The case against it is it only works with primitives.  If you set an
object/array on the prototype it's shared by all instances, which is
dangerous.

On Fri, Dec 12, 2014 at 10:15 PM, Glen Huang curvedm...@gmail.com wrote:

 I agree data properties on the instance prototype is a bad idea. But
 static properties are really useful. Could we at lease allow them:

 class Foo {
   static bar = 43;
 }

 On Dec 13, 2014, at 12:53 PM, Kevin Smith zenpars...@gmail.com wrote:

 function Foo() {}
 Foo.bar = 1;
 Foo.prototype.baz = 2;

 Is it possible to allow this in es6 with the class syntax? Or it belongs
 to es7? Or it’s simply a terrible idea?


 Data properties on the instance prototype are generally considered to be a
 footgun.  If you want to expose a data-like property on the constructor (or
 the instance prototype), you can use accessors:

 let _bar = 1;
 class Foo {
 static get bar() { return _bar; }
 static set bar(value) { _bar = value; }
 }
 Foo.bar = 43;



 ___
 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: Define static properties and prototype properties with the class syntax

[Frankie Bagnardi]

You're much better off subclassing menu for that purpose.

class Menu
constructor(options) {
this.options = Object.assign({hidden: false}, options);
}
}

class HiddenMenu extends Menu {
constructor(options){
super(Object.assign({hidden: true}, options));
}
}


On Sat, Dec 13, 2014 at 2:54 AM, Glen Huang curvedm...@gmail.com wrote:

 But allowing getter  setter already makes it dangerous:

 let _bar = {}
 class Foo {
 static get bar() { return _bar; }
 }

 Objects that have Foo.prototype in the prototype chain can do this.bar.a
 = 1, and the change won’t be shadowed.

 I found myself looking for a way to define static properties because I
 want to do this:

 function Menu(options) {
 this.options = Object.assign({}, Menu.defaults, options);
 }
 Menu.defaults = { hidden: false };

 I want to expose the defaults property so it can be modified by users.
 This pattern is very ubiquitous in es5. I wonder if the class syntax could
 allow this pattern to be carried to es6?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Define static properties and prototype properties with the class syntax

[Frankie Bagnardi]

It's an antipattern to modify things you didn't create, and jQuery is the
embodiment of this antipattern :-)

If you really need to do this, you should also put a comment saying Modify
Menu.defaults to change the default settings.  And put it in any docs that
go with it.



On Sat, Dec 13, 2014 at 3:35 AM, Glen Huang curvedm...@gmail.com wrote:

 Thanks for the sample code.

 But the defaults actually contains other properties like width, height,
 etc that let users customize the constructed menu object. So subclass won’t
 work here.

 A lot jquery plugin are actually written this way:

 http://learn.jquery.com/plugins/advanced-plugin-concepts/

 Look at the first example, A defaults property is attatched to the
 constructor.

 On Dec 13, 2014, at 6:20 PM, Frankie Bagnardi f.bagna...@gmail.com
 wrote:

 You're much better off subclassing menu for that purpose.

 class Menu
 constructor(options) {
 this.options = Object.assign({hidden: false}, options);
 }
 }

 class HiddenMenu extends Menu {
 constructor(options){
 super(Object.assign({hidden: true}, options));
 }
 }


 On Sat, Dec 13, 2014 at 2:54 AM, Glen Huang curvedm...@gmail.com wrote:

 But allowing getter  setter already makes it dangerous:

 let _bar = {}
 class Foo {
 static get bar() { return _bar; }
 }

 Objects that have Foo.prototype in the prototype chain can do this.bar.a
 = 1, and the change won’t be shadowed.

 I found myself looking for a way to define static properties because I
 want to do this:

 function Menu(options) {
 this.options = Object.assign({}, Menu.defaults, options);
 }
 Menu.defaults = { hidden: false };

 I want to expose the defaults property so it can be modified by users.
 This pattern is very ubiquitous in es5. I wonder if the class syntax could
 allow this pattern to be carried to es6?




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default values of destructured arguments?

[Frankie Bagnardi]

Traceur supports the former (6to5 doesn't).  I think both of those should
be valid, the former just because it makes sense (likely why it accidently
works in traceur), and the latter because it's very useful.

http://jsbin.com/bevijekiki/1/edit

These should be equivalent (minus the o variable)

function({d=1}){}
function(o){ var d = o instanceof Object  o.d !== undefined ? o.d : 1 }



On Fri, Nov 28, 2014 at 8:45 AM, Bradley Meck bradley.m...@gmail.com
wrote:

 I might be missing something but it appears in es6 you cannot default a
 destructured argument?

 ```
 function foo({d}={d:1}) {

 }
 ```

 and

 ```
 function foo({d=1}) {

 }
 ```

 don't seem to fall into the syntax, are there plans for this in the future
 or something that prevented this?

 ___
 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: Default values of destructured arguments?

[Frankie Bagnardi]

Odd, traceur seems to be fine with function({d=1}){ return d }() === 1

http://jsbin.com/birajevaxi/2/edit

On Fri, Nov 28, 2014 at 9:15 AM, Kevin Smith zenpars...@gmail.com wrote:

 function({d=1}){}
 function(o){ var d = o instanceof Object  o.d !== undefined ? o.d : 1 }


 Not exactly - see my previous post.  You've supplied a default
 destructuring value, but not a default *parameter* value.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default values of destructured arguments?

[Frankie Bagnardi]

Ah yep, it appears so.

On Fri, Nov 28, 2014 at 9:26 AM, Kevin Smith zenpars...@gmail.com wrote:

 Try this:


 http://google.github.io/traceur-compiler/demo/repl.html#(function(%7Bd%3D1%7D)%7B%20return%20d%20%7D()%20%3D%3D%3D%201)%0A

 Maybe an old version or traceur on jsbin?


 On Fri, Nov 28, 2014 at 11:17 AM, Frankie Bagnardi f.bagna...@gmail.com
 wrote:

 Odd, traceur seems to be fine with function({d=1}){ return d }() === 1

 http://jsbin.com/birajevaxi/2/edit

 On Fri, Nov 28, 2014 at 9:15 AM, Kevin Smith zenpars...@gmail.com
 wrote:

 function({d=1}){}
 function(o){ var d = o instanceof Object  o.d !== undefined ? o.d : 1
 }


 Not exactly - see my previous post.  You've supplied a default
 destructuring value, but not a default *parameter* value.




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Syntax sugar for single exit and early exit functions.

[Frankie Bagnardi]

Returning false isn't the common way to prevent the default action anymore,
event.preventDefault() is.  In that case you'd just preventDefault at the
top of your function.

The other use cases can be satisfied with simple high order functions like
andReturn(f, x) or compose(f, g).

On Sun, Nov 16, 2014 at 5:07 PM, Biju bijumaill...@gmail.com wrote:

 I wish, I could write elegant two of the code pattern I use frequently.

 Patten 1.
 HTML button click event handler should always return false (ie, when
 you never want the submit action).
 So I always write.

 function someClickHandler(){
   try {
 doStuff();
 doAnotherStuff();
 doYetAnotherStuff();
   } catch(e){
   }
   return false;
 }


 Patten 2.
 I do like to code functions with early exit, like

 function someValidationProcess(){

 doStuff();
 if(condition_1()){
 doCleanUp_1();
 doCleanUp_2();
 }

 doAnotherStuff();
 if(condition_2()){
 doCleanUp_1();
 doCleanUp_2();
  }

 doYetAnotherStuff();
 if(condition_3()){
 doCleanUp_1();
 doCleanUp_2();
  }

 doMoreStuff();
 doCleanUp_1();
 doCleanUp_2();
 }


 Proposal:
 I wish there was some syntax sugar like

 function someClickHandler(){
 doStuff();
 doAnotherStuff();
 doYetAnotherStuff();
 } finally {
return false;
 }


 function someValidationProcess(){

 doStuff();
 breakif(condition_1());

 doAnotherStuff();
 breakif(condition_2());

 doYetAnotherStuff();
 breakif(condition_3());

 doMoreStuff();

 } finally {
 doCleanUp_1();
 doCleanUp_2();
 }


 Cheers
 ___
 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: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

[Frankie Bagnardi]

Consider when Array.isArray would be used.  In my experience, checks to see
if something is an array are used for:

 - deciding how to iterate it (for(;;) vs for..in, for example)
 - deciding if the output should be an array or plain object (e.g. lodash)
 - early errors, e.g. runtime typecheck errors

In all of these situations, I don't care if it is an actual per-spec exact
array, I care if I can use it like an array.  That's how Array.isArray will
likely be used, and if it runs into problems, then expect github to be full
of 'don't use Array.isArray' patches on many libraries, much like the
existing instanceof situation.





On Sun, Nov 16, 2014 at 11:20 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 11/16/14, 2:12 AM, Brendan Eich wrote:

 Are you confident this change is web-compatible?


 No, I said that up-thread already.  So there may be nothing to worry about
 here spec-wise for now.

 -Boris



 ___
 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: Maximally minimal stack trace standardization

[Frankie Bagnardi]

I think this is a great idea.  I often use stack traces, especially in
node.js, for debug error messages and logging.  This would make it much
simpler to work with them.

Also there are some libraries which end up with a lot of wrapped functions,
which could be omitted using an error cleaner function.

I suggest a stackTrace property (getter, no write) of Error objects:

 - .frames is an array of stack frame metadata objects
 - no concept of sourcemaps
 - [[ToString]] is left implementation dependant, allowing them to add
information from sourcemaps, or otherwise customize it

This allows for a programmable api, and a human readable version.  Also
devtools and other code applications (like Carl Smith's) can create rich
UIs for this data.

I'm sure the smart people at TC39 can come up with a good (or good enough)
way to represent PTCs.



On Sat, Oct 4, 2014 at 9:31 AM, John Lenz concavel...@gmail.com wrote:

 Is ES6 shipping PTCs without implementer feedback? Or how have those
 that tried dealt with stack traces?
 On Sep 29, 2014 3:20 PM, John Lenz concavel...@gmail.com wrote:

 What does TC39 expect with regard to PTC and the
 standard-because-everyone-has-one stack property?   Has any of the VMs
 actually tried to implement PTC for JS?

 On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich bren...@mozilla.org
 wrote:

 Allen Wirfs-Brock wrote:

 No particular reason an implementation can't optimize through that if
 they want to.


 The question is whether it should be normative. PTC is about observable
 asymptotic space performance (I keep saying :-P).

 /be

 ___
 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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

[Frankie Bagnardi]

You can also do a split-join to get a literal replace.

 I'll sell this for {cost}..split({cost}).join($5.00);
I'll sell this for $5.00.



On Tue, Jul 29, 2014 at 9:36 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 '0101'.replace('0', function(){return 1}) == '1101'

 so your last two are the same:

 replace(string, callback) - called one time, using the first indexOf and
 replacing it invoking the callback
 replace(string, string) - called one time, using the first indexOf and
 replacing it via provided string and checking $



 On Mon, Jul 28, 2014 at 10:29 PM, Christoph Martens cmarten...@gmail.com
 wrote:

  On 28.07.2014 17:24, Rick Waldron wrote:




 On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 7/28/14, 11:09 AM, Rick Waldron wrote:

var y = x.replace('{{blob}}', function() {
  return data;
});


  In fairness, that's the sort of thing that gives off a WAT smell.
 Code like this without a comment that explains the indirection is just
 asking someone to simplify it, breaking it in the process...


  I don't disagree with your feedback, but JS has had special semantics
 for $ (with ’ or n) character in the replaceValue since ES3 (just short
 of 15 years). I didn't say that the solution was obvious, just that it
 required familiarity ;)

  Rick


 ___
 es-discuss mailing 
 listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss


 Hey Rick,

 To be honest, I didn't know the trick with the dummy filter function
 returning the plain data. I expected that it was executed each time a match
 was found (similar to Array filter functions).

 I think for external guys writing JavaScript, the WAT effect is pretty
 huge. Either we should change the behaviour of the parameters (which is bad
 for legacy implementations) or the flags to disable it optionally.

 As I wasn't familiar with the replace behaviour before, I would expect
 the method to behave differently, depending on the arguments:


 replace(regexp, string) - parse string and see if $ is in there
 replace(regexp, callback) - callback is called each time regexp is
 matched
 replace(string, callback) - only called once
 replace(string, string) - called one time, using the first indexOf and
 replacing it


 ~Chris


 ___
 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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.replace() problems with JSON.stringify() and serialization of Objects

[Frankie Bagnardi]

Of course it's a hack :-)

So, moving forward, it'd have to be an extra method on strings, that only
provides a small change in behavior.  It's probably not going to happen
because it's such a small change.

Potentially a S.p.replaceAll which has the same behavior as split-join in
that: a b a c a d.replaceAll(a, X) = X b X c X d.

But then you end up with similar concerns to those expressed in the current
.contains thread (it's inconsistent).




On Tue, Jul 29, 2014 at 1:32 PM, Rick Waldron waldron.r...@gmail.com
wrote:




 On Mon, Jul 28, 2014 at 10:29 PM, Christoph Martens cmarten...@gmail.com
 wrote:

  On 28.07.2014 17:24, Rick Waldron wrote:




 On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 7/28/14, 11:09 AM, Rick Waldron wrote:

var y = x.replace('{{blob}}', function() {
  return data;
});


  In fairness, that's the sort of thing that gives off a WAT smell.
 Code like this without a comment that explains the indirection is just
 asking someone to simplify it, breaking it in the process...


  I don't disagree with your feedback, but JS has had special semantics
 for $ (with ’ or n) character in the replaceValue since ES3 (just short
 of 15 years). I didn't say that the solution was obvious, just that it
 required familiarity ;)

  Rick


 ___
 es-discuss mailing 
 listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss


 Hey Rick,

 To be honest, I didn't know the trick with the dummy filter function
 returning the plain data. I expected that it was executed each time a match
 was found (similar to Array filter functions).

 I think for external guys writing JavaScript, the WAT effect is pretty
 huge. Either we should change the behaviour of the parameters (which is bad
 for legacy implementations)


 The progress of JS is limited only to non-web-breaking changes.


 Rick


 ___
 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: Re: [PROPOSAL] use keyword

[Frankie Bagnardi]

I see where this might be convenient, but the down sides are much larger,
similar to `with`, `eval`, or arbitrary global variables.  It essentially
destroys the ability of compilers, tools, and people to statically analyze
the code.

I'm all for laziness in code (e.g. destructuring), but not when it causes
significant problems.

Michaël, sorry, but I think this is a lost cause.




On Fri, Jul 25, 2014 at 3:05 PM, Michaël Rouges michael.rou...@gmail.com
wrote:

 @ Rick :

 Or a more controlled solution might be to create a method able to only
 attach one pointer at a time.

 What do You think about it?

 ___
 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: RegExp spec question

[Frankie Bagnardi]

You could wrap it in an iterator :-)

http://www.es6fiddle.net/hxoczoqg/

```javascript
function* match(regex, haystack){
  var {source, ignoreCase} = regex;
  var newRegex = new RegExp(source, ignoreCase ? 'gi' : 'g');
  var m = null;
  while (m = newRegex.exec(haystack)) {
  yield m;
  }
}

var input = I have 5 dogs, 3 cats, and 49 ants.;

for (let num of match(/\d+/, input)) {
console.log(num);
}
```



On Wed, Jul 16, 2014 at 12:53 AM, Axel Rauschmayer a...@rauschma.de wrote:

 Yes, the /g flag is confusing, because the regular expression kind of
 turns into an iterator. I’d much prefer an actual iterator-based API that
 doesn’t mutate the regular expression.

 On Jul 16, 2014, at 9:26 , Alex Vincent ajvinc...@gmail.com wrote:

 r = /\u0020+$/g; p = r.exec(  ); q = r.exec(  ); JSON.stringify([p, q])
 // [[\  \],null]

 Why does calling exec the second time generate null?  When I try the
 regular expression without the /g flag, I get:
 // [[\  \],[\  \]]



 --
 The first step in confirming there is a bug in someone else's work is
 confirming there are no bugs in your own.
 -- Alexander J. Vincent, June 30, 2001
 ___
 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: Math.TAU

[Frankie Bagnardi]

It's pretty useless to have.  If you need the TAO constant often, rather
than setting it on Math you'd be better off having local variables.  This
is both for conciseness and minification (minified Math.TAO is Math.TAO,
minified TAO is a single character).

```javascript
var PI = Math.PI, TAO = PI * 2;
var area = (r) = PI * (r * r)
var circ = (r) = TAO * r
```

Or even:

```javascript
var π = Math.PI, τ = π * 2;
var area = r = π * (r * r)
var circ = r = τ * r
```





On Mon, Jun 30, 2014 at 2:58 AM, alawatthe alawat...@googlemail.com wrote:

 Although I'm a mathematician, I don't want to argue from a mathematical
 point of view against the inclusion of Math.TAU
 (For this please read the http://www.thepimanifesto.com/ which was
 already posted above by Michael).
 But instead from a JavaScript point of view:

 The only arguments in favor of Math.TAU so far were:

 Another +1. Would save me doing Math.TAU = 2 * Math.PI; at the top of all
 my trignometry files :-)


 That is not really a compelling argument for Math.TAU. And seeing the
 smiley I don't even think you meant it serious.

[…] It's a fairly harmless easter egg.


 Yes, it is. But (apart from the question whether we should include easter
 eggs in the language)
 aren't there easter eggs, which have to do more with JavaScript and less
 with a pointless math argument?

 Are those really the two best arguments for Math.TAU?


 So now to the reasons against Math.TAU:

 I don't know a single programming language which includes the tau
 constant. Why should we?

 But the real reason why I'm against the inclusion of Math.TAU is the
 following:

 Brendan you said once that Math is becoming a dumping ground see here
 https://mail.mozilla.org/pipermail/es-discuss/2013-November/034610.html
 (So it surprised me much, that you want to champion Math.TAU at the next
 TC39 meeting.)

 I don't think that Math is a dumping ground (or becoming one), but I see
 no reason to include a property we don't need
 and make the Math object even more looking like a dumping ground to some
 people.
 Instead of tau we could add more useful things to the Math object like the
 gamma function and the error function.
 (I’m pretty sure that as soon as I propose those functions, someone will
 come with the dumping ground argument.)

 -- alawatthe aka alex

 ___
 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: JSON.stringify and symbols

[Frankie Bagnardi]

It also skips explicit undefined values.  Basically, if there's no good
JSON representation of something, it pretends it doesn't exist.

You can also get this behavior by doing `obj.toJSON = () = undefined`
[example fiddle][1]

In all of those cases symbols behave as if they were the value `undefined`,
or an object with a toJSON which returns undefined.

[1]: http://jsfiddle.net/MRUj6/


On Mon, Jun 30, 2014 at 12:55 PM, Mark S. Miller erig...@google.com wrote:

 JSON.stringify also skips function-valued properties, which seems even
 more weird. I think this is fine as long as it can be overridden by
 replacers and resolvers.



 On Mon, Jun 30, 2014 at 11:37 AM, Jason Orendorff 
 jason.orendo...@gmail.com wrote:

 As specified in the latest draft:

 1. JSON.stringify(symbol) returns undefined.

 2. JSON.stringify([symbol]) returns [null].

 3. JSON.stringify(object) skips any symbol-keyed properties on the object.

 So far, so good, I guess. A little wonky maybe, but JSON doesn't have
 symbols, so sure.

 This struck me as funny though:

 4. JSON.stringify(object) also skips symbol-valued properties.

 That is, JSON.stringify({x: Symbol()}) == {}. I don't know that
 there's anything more useful it should be doing instead. Thoughts?

 -j
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




 --
 Cheers,
 --MarkM

 ___
 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: Math.TAU

[Frankie Bagnardi]

String.prototype.endsWith and Object.is are functions, and their JS
implementations are nontrivial to memorize and type (although not the worst
examples).  Memorizing PI to more than a few digits is nontrivial.  Same
with Math.E, or Math.atan2, or most of the other Math functions and
properties.

Remembering that PI*2 is TAO is required to even make use of it,
unless/until mathematicians, books, and wikipedia start using TAO where 2
PI is currently used, you have to convert them.  So if you decide to used
it, you already know the definition.  The alternative to other things in
JavaScript (for the most part) spending time researching how to implement
it, comparing existing implementations, or having to look up a constant
value (e.g. 3.141592653589793).

Seems a little silly, and I'd rather see some of the use cases for it end
up on Math if anything.


On Mon, Jun 30, 2014 at 4:55 PM, Alex Kocharin a...@kocharin.ru wrote:



 30.06.2014, 21:09, C. Scott Ananian ecmascr...@cscott.net:

 On Mon, Jun 30, 2014 at 1:01 PM, Rick Waldron waldron.r...@gmail.com
 wrote:

 Just because other languages don't include a TAU constant doesn't mean
 ECMAScript cannot.

 Just because serious mathematicians think this is crackpot territory,
 doesn't mean it's not useful (the condescension of that claim certainly
 isn't).


 As I mentioned, although I am a pi-ist, I think Math.TAU is harmless.  But
 I will qualify the not useful part -- there is no numerical accuracy
 benefit to using Math.TAU (only the floating point exponent changes), nor
 is there likely to be any emitted-code improvement (constant propagation
 being a standard part of any reasonable runtime).  So the benefit is solely
 the single character minimized code size improvement from '2*Math.PI' to
 'Math.TAU' (if this were significant wouldn't the minimizers be assigning
 this to a single-character variable already?)



 It's not about code size or numerical accuracy. When developing HTML5
 games where a lot of trigonometric calculus takes place, I'm used to see
 2*Math.PI more often than Math.PI by itself. People usually treat it as one
 single constant (which is prone to errors if someone writes 1/2*Math.PI
 instead of 1/(2*Math.PI)). It's just better to replace it with one constant
 than having this multiplication appear everywhere.

 So I'd like to see this make its way to the standard... it's certainly
 more useful than, say, String.prototype.endsWith or Object.is :)

 // alex

 ___
 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: ES6 modules (sorry...)

[Frankie Bagnardi]

The other big concern here is that in production, very few people are going
to be loading every JavaScript file asynchronously.  If there's magic,
there needs to be a reasonable way to handle bundling multiple ES6 files
together.

The [current solution][1] turns it into common.js (or others) and does
destructuring.  You then use browserify or similar tools to get your
bundles.  Perhaps a whole tool for ES6 modules will rise, but we have to
make sure that the magic doesn't mean only implementable natively.  It
needs to be something people can use today in ES5 browsers... or else we'll
have broken ES6 modules and no one will be able to use real ES6 modules.

I'm sure people working on the proposal thought of this, so what was the
reasoning?



[1]: https://github.com/square/es6-module-transpiler


On Mon, Jun 16, 2014 at 12:24 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:

 Another alternative is to introduce this funny binding not
 destructing behavior as a first-class language construct, so that one
 could do:

 ```
 let o = { f: 1 };
 let  f  = o;  // using your angle-bracket syntax for the sake of
 discussion
 o.f = 2;
 console.log(f); // prints '2'

 let  foo  = import module; // same syntax!
 ```

 Of course this is far too large a change for this late date, etc, etc.
 But my point is that modules as objects works well because it fits
 well with the rest of the language.  If we want `f` to be an
 abbreviation for `o.f` then it would be nice if that binding behavior
 was part of the base language.
   --scott

 ps. my personal preference is *not* to introduce new 'binding' syntax,
 but instead to imagine the values assigned as a result of the
 destructuring as being somewhat magical proxies which retain their tie
 to the original module object and reflect changes there.  Using
 proxies as a mental model of the semantics avoids having to muck
 around with the core notion of variable binding.  That is, it really
 is a `let`, and it really is ordinary `destructuring` -- all the magic
 resides in the particular value returned.
 ___
 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: My ECMAScript 7 wishlist

[Frankie Bagnardi]

Couldn't preventUndeclaredGet() be implemented with proxies?

It actually sounds like an extremely useful feature for development builds
of libraries and applications.  Typos are very very common, and often
difficult to look over while debugging.  On the other hand, it would break
a lot of existing code if you try to pass it as an object to a library;
you'd have to declare every possible value it might check (which
isn't necessarily bad).  Most of the time, it's just an options object, or
an object it'll iterate over the keys of.

Using it on arrays would also reduce off-by-1 errors (though I don't see
them often in JS).




On Fri, Jun 6, 2014 at 7:37 AM, David Bruant bruan...@gmail.com wrote:

  Le 06/06/2014 15:57, Mark S. Miller a écrit :

 By contrast, a Map's state is more like the private instance variable
 state of a closure or a post-ES6 class.

 The capabilities to arbitrarily modify Maps (set/delete on all keys, with
 any values) will be expected by any ES6-compliant code to be globally
 available, so a Map's state cannot reasonably be considered private.
 This differs from the state of a closure where its access is strictly
 moderated by the public API giving access to it and to the fact that this
 API is not provided globally (unlike Map.prototype).


   Object.freeze of a Map should not alter the mutability of this state
 for the same reason it does not alter the state captured by a closure or a
 future class instance.

 I'd argue the Map state is very much like regular objects (for which you
 can't deny [[Set]], [[Delete]], etc.), not closure's state.

 In an ES6 world, denying access to the global Map.prototype.* would break
 legitimate code, so that's not really an option confiners like Caja could
 provide.




 or should an Object.makeImmutable be introduced? (it would be freeze +
 make all internal [[*Data]] objects immutable)


  We do need something like that. But it's a bit tricky. A client of an
 object should not be able to attack it by preemptively deep-freezing it
 against its wishes.

 I don't see the difference with shallow-freezing?
 It's currently not possible to defend against shallow-freezing (it will be
 possible via wrapping in a proxy).



 This can be achieved with Proxy right, or is that too cumbersome?

  Code-readability-wise, wrapping in a proxy is as cumbersome as a call to
 Object.preventUndeclaredGet I guess.

 This sort of concerns are only development-time concerns and I believe
 the runtime shouldn't be bothered with these (I'm aware it already is in
 various web). For instance, the TypeScript compiler is capable today of
 catching this error. Given that we have free, cross-platform and fairly
 easy to use tools, do we need assistance from the runtime?


  Yes. Object.freeze is a runtime production protection mechanism, because
 attacks that are only prevented during development don't matter very much
 ;).

 Just to clarify, I agree that Object.freeze was necessary in ES5 (have we
 had proxies, it might have been harder to justify?), because there was no
 good alternative to protect an object against the parties it was shared
 with.
 But the concern Nicholas raises doesn't seem to have this property.
 Reading a property that doesn't exist doesn't carry a security risk, does
 it? Object.preventUndeclaredGet doesn't really protect against anything
 like ES5 methods did.

 David

 ___
 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