Re: A plan to help TC39 become more open up to community contributions and participations

@John @Michał ES6 expanded the language greatly indeed, but the expansion is incomplete with lots of glaring holes. I happen to be researching into the crazily deficient Map/Set APIs recently as well, and found a few documents - only from 1.5 years ago but apparently are quickly falling out of

Re: A plan to help TC39 become more open up to community contributions and participations

First - thanks for everyone who chipped in; any comment is of immense value here. @Kevin **The "us-vs-them" mentality**: IMHO the mentality kinda came into existence precisely because of the aforementioned fact that the current experience for community participation is not a smooth and - more

Re: A plan to help TC39 become more open up to community contributions and participations

To be honest - I can rather see complaining about how small is the standard library, and how many basic functions have to be provided by third party, not by standard library (famous left-pad case). And I think these complaints are right and justified - newly introduced classes like Set are

Re: Suggestion: "Object.hasOwnProperty"

Reflect is only for API mirrors to Proxy traps - that's why Reflect.enumerate was removed along with the Enumerate Proxy trap. On Friday, May 27, 2016, Isiah Meadows wrote: > I'd, for ergonomic reasons, would prefer it on Reflect. I very frequently > alias this function,

Re: Error-Type Specific try/catch Blocks

I still can't see why it's superior to standardizing SpiderMonkey non-standard syntax. ``` try { ... } catch(e if e instanceof Error) { } ``` I think it's rather inferior, because your doesn't allow C#-like exception filters. It saves you 14 characters, but limits your "easy" filters to

Re: A plan to help TC39 become more open up to community contributions and participations

Maybe also a factor: JS has changed a huge amount in a short time. Developers, browsers, tools need to catch up, digest the changes, decide what real problems remain. We have enough new for now. On Fri, May 27, 2016 at 7:42 AM, Kevin Smith wrote: > Thanks for pointing out

Re: A plan to help TC39 become more open up to community contributions and participations

Thanks for pointing out some issues with the current state of things. While, in general, having more people directly participate in the committee is probably a good thing, I don't think that will fix the problem. I think you'll find yourself running into the same troubles that the current members

Re: Error-Type Specific try/catch Blocks

Shiny... On Fri, May 27, 2016, 05:06 Arthur Stolyar wrote: > Something wrong with prev link. > https://github.com/zenparsing/es-typed-catch > On May 27, 2016 12:00, "Arthur Stolyar" wrote: > >> If something, here seems to be another similar

Re: Suggestion: "Object.hasOwnProperty"

I'd, for ergonomic reasons, would prefer it on Reflect. I very frequently alias this function, so having it as a static method on Reflect would be nice. On Thu, May 26, 2016, 17:42 doodad-js Admin wrote: > >> This would break a Web, a I have seen code that relies on >

Re: es-discuss Digest, Vol 111, Issue 83

Try sending it with `unsubscribe` as the subject and no text. Or you could always go to the link and do it from there. ;-) On Thu, May 26, 2016, 16:28 Will wrote: > unsubscribe > > On Thu, May 26, 2016 at 4:21 PM, wrote: > >> Send es-discuss

Re: Import wildcards

With this syntax, you would not be able to statically tell whether a particular variable name (e.g. API_FOO) is bound to a module import, without also analyzing the dependencies (and perhaps their dependencies). These considerations killed the original "import all" syntax. (`import * from

Import wildcards

Hi, In about every project I have, I write a file or two with this form: export let API_USERNAME = `name` export let API_TOKEN = `token` // etc Most of the time, when I need one of those variables somewhere, I also need the other. It might be burdensome, since I end up with

Re: Error-Type Specific try/catch Blocks

Something wrong with prev link. https://github.com/zenparsing/es-typed-catch On May 27, 2016 12:00, "Arthur Stolyar" wrote: > If something, here seems to be another similar proposal: > https://github.com/zenparsing/es-typed-catch >

Re: Error-Type Specific try/catch Blocks

If something, here seems to be another similar proposal: https://github.com/zenparsing/es-typed-catch ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss