Re: Suggestion: Object.symbols

I believe Symbols are all actually non-enumerable which will void the suggestion. And please, stop trying to add all kinds of trivial variations of property extraction methods already. I also oppose the recently proposed Object.enumerableKeys and gang. On Thu, Jun 16, 2016 at 9:25 AM, doodad-js

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

Hi Allen, thanks for extending your support :-D My observation as well as belief is that, if a community effort has turned out to be successful, than volunteers will flock together and the movement / organization will be able to self-sustain for quite long enough. So the issue has always been how

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

I'll add that after much contemplation, it *might not* be a wise idea to delegate anyone who wish to attend a certain TC39 meeting as the nonprofit's representative; I cannot tell whether the advantages it brings could outweight the problems that would also come as a result. So perhaps we'll hold

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

see some good ones from the community. Again **due to Ecma International's IPR policies**, we need a community member inside TC39 itself to enable this possibility. On Sat, May 28, 2016 at 10:41 AM, G. Kay Lee < balancetraveller+es-disc...@gmail.com> wrote: > First - thanks for eve

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: Reflect.create()

Hi Even, I think everyone who has replied above has all been offering some very constructive feedbacks for you to chew on. The key takeway, if you haven't noticed already, is that your understanding of the language is flawed, and people simply cannot help you or continue their discussions with

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

f we can make things work even better for the community and the language. *G. Kay Lee* github.com/gsklee ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: How about a "named true" and a "named true property"

Here you go... ``` var deep; $.extend(!deep, object1, object2); // true $.extend(!!deep, object1, object2); // false ``` What you're asking is essentially another `!`. On Thu, May 26, 2016 at 5:02 PM, Gray Zhang wrote: > I don't really know how to name this feature, but

Re: Observing whether a function is strict

I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish

Re: Get currently destructured object

I suspect OP misunderstood the destructuring syntax, otherwise it made zero sense to me... FYI in the case of `({foo: bar}) => { ... }`, `bar` is the alias of `someObject.foo`, not the other way around. And it's a bad idea because instead of an ad-hoc solution which is gonna waste another

Re: Error-Type Specific try/catch Blocks

self. It didn't work. You can > find previous talk by searching esdiscuss.com via Google.) > > On Sat, May 14, 2016, 12:17 G. Kay Lee < > balancetraveller+es-disc...@gmail.com > <javascript:_e(%7B%7D,'cvml','balancetraveller%2bes-disc...@gmail.com');>> > wrote: > >&

Re: Error-Type Specific try/catch Blocks

This is another really far shot - but I'd rather suggest that we should redefine the role of `case` so that it's no longer just a part of the `switch` statement but something more generic, as well as introducing a `match` keyword to enable pattern matching, including the power of matching by type,

Re: Re: Tracking proposals should be standardized with issues

mail.com> wrote: > Clarification: Bocoup is not a member of Ecma. Leo, Yehuda and I are > representatives for jQuery Foundation, which is a member. > > Rick > > On Wed, May 11, 2016 at 10:12 PM Domenic Denicola <d...@domenic.me> wrote: > >> From: es-discu

Re: Tracking proposals should be standardized with issues

Sorry but this is confusing. So any employee of TC39 member organizations can be a champion? On Thursday, May 12, 2016, Domenic Denicola <d...@domenic.me> wrote: > From: es-discuss [mailto:es-discuss-boun...@mozilla.org <javascript:;>] > On Behalf Of G. Kay Lee > > >

Re: Re: Tracking proposals should be standardized with issues

start using it in Babel TODAY!" and make an impression to the JS community that their creations are something new and trendy and of the current state-of-the-art. On Thu, May 12, 2016 at 7:47 AM, G. Kay Lee < balancetraveller+es-disc...@gmail.com> wrote: > > I haven't see

Re: Re: Tracking proposals should be standardized with issues

> I haven't seen many proposals actually born in the ML, I've rather seen tons of proposals discussed offline and/or suddenly part of some repo/site/post/strawman. Yes you are so right. Just a few hours ago we have yet another new [stage 0

Re: operator overloading proposal

> const v = new Point(1, -2); > > const w = u + v; // desugars to u[Symbol.add](v) > console.log(w); // { x: 6, y: 8 }; > ``` > > This would require default implementations to be defined on > Object.prototype for Symbol.plus, Symbol.times, etc. > > > On Sun, May 8, 20

Re: Proposing a conditional assignment (or equals) operator

Not convinced. Failed to see any reason why this proposal could force its way through this time after repeatedly being raised from dead only to be put down time after time. I don't see any new, convincing rationales here. On the other hand I can give out two reasons on why we don't need this thing

Re: operator overloading proposal

but last I > heard of it, they say it's going to make its way into the standard pretty > soon (TM), and macros can do much of the things overloading could, and much > more. > > I haven't seen any proposals for macros, could you post a link? > > > > > > > > On Sat

Re: operator overloading proposal

I'd say it's way too early to ask for a champion on this because just a quick skimming revealed a lot of places that didn't add up. For example, the proposal suggested that overloading is primarily targeted at making it easier to work with user-defined classes, but curiously a