proposal: Object Members

Ranando King kingmph at
Thu Jul 26 06:28:50 UTC 2018

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` &
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
5. Prevent the breaking of the `obj.field === obj['field']` usage pattern
6. Prevent the unnecessary isolation of functionality into the `class`
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

On Wed, Jul 25, 2018 at 2:23 AM T.J. Crowder <
tj.crowder at> wrote:

> On Mon, Jul 23, 2018 at 8:38 PM, Ranando King
> <kingmph at> 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]( 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]:
> [2]:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list