Let me see if I can clarify things a bit: You're not misunderstanding. I've spent a fair amount of time in discussion on github in those very same issues. For various reasons, probably mostly due to the time investment the proponents of those proposals have given, it seems to be the prevailing view that the proposal as it stands, not withstanding the many glaring issues its detractors keep raising, is the best possible proposal that can be given. What I'm doing with my proposal is raising a formal counter-argument. I'm not simply developing a new proposal adhoc. Instead, I'm taking advantage of the many points and issues raised about the existing proposals and integrating the best possible solutions I and others can come up with that haven't been shot down for any logical or rational reason into a single new, self-coherent, non-binding, and mostly "means what you'd expect at first glance" proposal.
My goals are straight forward. I'll list them: 1. Introduce the concept of non-public privilege levels (`private` & `protected`) 2. Introduce a self-consistent means of accessing non-public members (operator `#`) 3. Introduce a means of declaring non-public members **with and without** the `class` keyword 4. Prevent the introduction of special case characters in an `[[IdentifierName]]` 5. Prevent the breaking of the `obj.field === obj['field']` usage pattern 6. Prevent the unnecessary isolation of functionality into the `class` keyword 7. Prevent the unnecessary limiting of future language expansion due to excessively limiting new feature. Truth be told, the proposal I'm offering can be thought of as a heavy handed revision of the two proposals above. I am presently adding to my proposal a description of the implementation details required to make it all work. I hope that at the very least, from this you and others will be able to see that there is indeed a less limiting possibility than what has been proposed by proposal-class-fields. Even though I am submitting my own proposal, I will still continue to add my observations to the existing proposals. On Wed, Jul 25, 2018 at 2:23 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Mon, Jul 23, 2018 at 8:38 PM, Ranando King > <king...@gmail.com> wrote: > > I've written up a new draft proposal based on my own work with ES5 & ES6 > > compatible classes with fields. That can be found > > [here](https://github.com/rdking/proposal-object-members). I'm already > aware > > of the class-members proposal, but I think it breaks far to many > things... > > That's quite vague. > > Am I misunderstanding your intent here? It seems like you're proposing > dropping the existing Stage 3 proposals ([1][1], [2][2]) in favor of this > new proposal. Those proposals are the result of years of work and > collaboration. It seems like any issues you have with them would be better > addressed by raising issues on those proposals and engaging with the people > working on them, rather than suggesting just throwing them out entirely and > replacing them with something new and different. But perhaps I'm > misunderstanding your intent? > > -- T.J. Crowder > > [1]: https://github.com/tc39/proposal-class-fields > [2]: https://github.com/tc39/proposal-static-class-features/ >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
