!Re: proposal: Object Members

Fri Aug 3 21:06:23 UTC 2018

A keyword being reserved is NOT the same as "being a part of ES". `package`
is reserved too, but there's zero concept of packages in the language, and
absolutely no obligation for there ever to be one.

To reiterate, the existence of `private`, `public`, and `protected` as
reserved keywords in *no way* justifies including any, or all, of these
keywords in any language feature.

On Fri, Aug 3, 2018 at 12:36 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> My "private symbols" proposal supports it, but that's about it.
>
> I think the main thing is that the use case isn't really that large,
> so nobody's really thought about it. (You can always "pretend" it
> exists by creating a single private key that's just an object
> dictionary.)
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Fri, Aug 3, 2018 at 8:34 AM, Michael Theriot
> <michael.lee.theriot at gmail.com> wrote:
> > If I understand the terminology, "private dynamic properties" are easily
> > polyfilled via weakmaps?
> >
> > I actually think it's odd there is no attempt to implement dynamic
> > properties in the other "private properties" proposals.
> >
> >
> > On Friday, August 3, 2018, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> >>
> >> Okay, now that I look at that proposal, I see two issues right off:
> >>
> >> 1. It's *super incredibly boilerplatey* and verbose syntactically. I
> >> don't know very many people who'd be willing to downgrade very far
> >> from even what TypeScript has. (I'm specifically referring to the
> >> declarations here.)
> >> 2. `protected` on an object literal is next to useless. I've used that
> >> kind of feature almost never.
> >>
> >> I also find it odd you're supporting private dynamic properties. It
> >> does make polyfilling next to impossible, though.
> >>
> >> Just my 2 cents on it. (I glanced over this while very tired, so I
> >> probably missed several highlights. These are what stuck out to me.)
> >>
> >> -----
> >>
> >> Isiah Meadows
> >> contact at isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >>
> >> On Wed, Aug 1, 2018 at 11:54 PM, Ranando King <kingmph at gmail.com>
> wrote:
> >> > https://github.com/rdking/proposal-object-members/blob/
> master/README.md
> >> >
> >> > On Wed, Aug 1, 2018 at 2:01 AM Isiah Meadows <isiahmeadows at gmail.com>
> >> > wrote:
> >> >>
> >> >> Do you have a link to this proposal so I can take a look at it? It'd
> >> >> be much easier to critique it if I could see the proposal text.
> >> >> -----
> >> >>
> >> >> Isiah Meadows
> >> >> contact at isiahmeadows.com
> >> >> www.isiahmeadows.com
> >> >>
> >> >>
> >> >> On Wed, Aug 1, 2018 at 2:18 AM, Ranando King <kingmph at gmail.com>
> wrote:
> >> >> >> If you go back a few months, what you're proposing is *very*
> >> >> >> similar,
> >> >> >> at
> >> >> >> least functionally, to my previous iteration of my proposal:
> >> >> >
> >> >> > That functional similarity is intentional. After pouring over years
> >> >> > worth of
> >> >> > posts, I figured out what the vast majority of the
> >> >> > proposal-class-fields
> >> >> > detractors actually wanted: an elegant, easily recognized syntax
> for
> >> >> > adding
> >> >> > private members to objects.
> >> >> >
> >> >> >> My main problem was that trying to limit private properties to
> >> >> >> objects
> >> >> >> created within a scope got complicated in a hurry once you
> >> >> >> considered
> >> >> >> all
> >> >> >> the small details, and it just didn't seem simple anymore.
> >> >> >
> >> >> > I noticed that about your proposal too. I'm also pretty sure that
> >> >> > Daniel
> >> >> > E.
> >> >> > and Kevin G. ran into the same issues back during the
> >> >> > proposal-private-names
> >> >> > days which is why the private names concept is just an
> implementation
> >> >> > detail
> >> >> > in their current proposal. My proposal is made less complicated by
> >> >> > breaking
> >> >> > the problem down into the 3 pieces required to make it all work:
> >> >> > 1. a record to store private data
> >> >> > 2. an array to hold references to the schema records of accessible
> >> >> > private
> >> >> > data
> >> >> > 3. a schema record for the sharable data.
> >> >> >
> >> >> > In this way private = encapsulated on a non-function, protected =
> >> >> > private +
> >> >> > shared, and static = encapsulated on a function. It should be easy
> to
> >> >> > sort
> >> >> > out how the data would be stored given such simple definitions.
> These
> >> >> > simple
> >> >> > definitions also mean that encapsulation is naturally confined to
> >> >> > definitions. Attempts to alter that state lead to strange logical
> >> >> > contradictions and potential leaks of encapsulated data. I have
> >> >> > thought
> >> >> > of
> >> >> > the possibility that private data could be added after definition,
> >> >> > but
> >> >> > every
> >> >> > attempt I make to consider such a thing has so far led to a risk of
> >> >> > leaking.
> >> >> >
> >> >> > I've been working on some code that can serve as a proof-of-concept
> >> >> > in
> >> >> > ES6.
> >> >> > It will implement all of my proposal that can reasonably be
> >> >> > implemented
> >> >> > in
> >> >> > ES6 using Proxy. It's already in the proposal repository under the
> >> >> > POC
> >> >> > branch, but it's still a WIP. For now, it already supports
> inheriting
> >> >> > from
> >> >> > native objects. I'm working on subclassing right now. By the time I
> >> >> > get
> >> >> > done
> >> >> > (likely this coming Monday), it should support every feature in my
> >> >> > proposal.
> >> >> > I'm basically using it as a means to check the viability of my
> >> >> > proposal.
> >> >> >
> >> >> > On Tue, Jul 31, 2018 at 4:35 PM Isiah Meadows
> >> >> > <isiahmeadows at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> If you go back a few months, what you're proposing is *very*
> >> >> >> similar,
> >> >> >> at least functionally, to my previous iteration of my proposal:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> https://github.com/isiahmeadows/private-symbol-proposal/blob/
> c5c9781d9e76123c92d8fbc83681fdd3a9b0b319/README.md
> >> >> >>
> >> >> >> My main problem was that trying to limit private properties to
> >> >> >> objects
> >> >> >> created within a scope got complicated in a hurry once you
> >> >> >> considered
> >> >> >> all the small details, and it just didn't seem simple anymore. It
> >> >> >> only
> >> >> >> got more complicated when you started getting into the logistics
> of
> >> >> >> integrating with modules.
> >> >> >>
> >> >> >> So I've considered the issue and explored it pretty thoroughly - I
> >> >> >> *really* don't want private data to be limited to classes (which I
> >> >> >> dislike), but I did also previously have the concern of trying to
> >> >> >> limit who could define properties where.
> >> >> >>
> >> >> >> I will point out that you can prevent arbitrary private extension
> by
> >> >> >> simply doing `Object.preventExtensions(object)`. Because
> properties
> >> >> >> defined using private symbols are otherwise just normal
> properties,
> >> >> >> they still have to go through the same access checks normal
> >> >> >> properties
> >> >> >> have to, like [[IsExtensible]]. The only other concrete difference
> >> >> >> is
> >> >> >> that proxy hooks don't fire when you do things with private
> symbols.
> >> >> >>
> >> >> >> -----
> >> >> >>
> >> >> >> Isiah Meadows
> >> >> >> contact at isiahmeadows.com
> >> >> >> www.isiahmeadows.com
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Jul 31, 2018 at 3:09 PM, Ranando King <kingmph at gmail.com>
> >> >> >> wrote:
> >> >> >> >> What use case are you referring to here?
> >> >> >> >
> >> >> >> > In the case of SymbolTree, the objects in use are external.
> >> >> >> >
> >> >> >> >> I think there’s been a misunderstanding. Everybody agrees that
> >> >> >> >> that’s a
> >> >> >> >> bad pattern. It’s not what the point of private symbols would
> be.
> >> >> >> >> It’s
> >> >> >> >> not a
> >> >> >> >> target use case.
> >> >> >> >
> >> >> >> > That certainly puts my mind at ease.
> >> >> >> >
> >> >> >> >> As Isiah said, “all of the examples here I've presented are for
> >> >> >> >> scenarios
> >> >> >> >> where the state is related to the factory that created the
> >> >> >> >> objects.”
> >> >> >> >
> >> >> >> > If the factory that creates the objects is the also the only
> thing
> >> >> >> > trying to
> >> >> >> > store private information on those objects, then I understand
> >> >> >> > you're
> >> >> >> > only
> >> >> >> > looking for per-instance module-private data, possibly with the
> >> >> >> > ability
> >> >> >> > to
> >> >> >> > use common private names. If that's the case, then it really is
> >> >> >> > just
> >> >> >> > 2
> >> >> >> > simple extensions of my proposal:
> >> >> >> > * allow a Symbol when used as a private or protected property
> name
> >> >> >> > to
> >> >> >> > persist as the private Symbol name for the private instance
> field
> >> >> >> > on
> >> >> >> > each
> >> >> >> > object for which it is used.
> >> >> >> > * create an additional privilege level (internal) that places
> the
> >> >> >> > new
> >> >> >> > field's name in the [[DeclarationInfo]] of the function
> containing
> >> >> >> > the
> >> >> >> > declaration.
> >> >> >> >
> >> >> >> > The effect of using these 2 features together is that anything
> >> >> >> > within
> >> >> >> > the
> >> >> >> > same function as the declared Symbol will gain access to the
> >> >> >> > internal
> >> >> >> > field
> >> >> >> > of all objects using that Symbol as a field name.
> >> >> >> >
> >> >> >> > On Tue, Jul 31, 2018 at 1:36 PM Darien Valentine
> >> >> >> > <valentinium at gmail.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> > I'd say you've identified the common pattern, but that
> pattern
> >> >> >> >> > itself
> >> >> >> >> > is
> >> >> >> >> > a bad use case, and the use of private symbols as you have
> >> >> >> >> > defined
> >> >> >> >> > them
> >> >> >> >> > doesn't do anything to correct the technical issue.
> >> >> >> >>
> >> >> >> >> I think there’s been a misunderstanding. Everybody agrees that
> >> >> >> >> that’s a
> >> >> >> >> bad pattern. It’s not what the point of private symbols would
> be.
> >> >> >> >> It’s
> >> >> >> >> not a
> >> >> >> >> target use case.
> >> >> >> >>
> >> >> >> >> > Since you cannot stick new properties onto a non-extensible
> >> >> >> >> > object,
> >> >> >> >> > even
> >> >> >> >> > private symbols won't solve the problem with your use case.
> >> >> >> >>
> >> >> >> >> That appending private symbols to external objects which are
> >> >> >> >> frozen
> >> >> >> >> wouldn’t work doesn’t matter precisely because it’s not a
> target
> >> >> >> >> use
> >> >> >> >> case.
> >> >> >> >> That it doesn’t work reliably might even be considered a
> >> >> >> >> positive,
> >> >> >> >> since it
> >> >> >> >> discourages something we all seem to agree is not good
> practice.
> >> >> >> >>
> >> >> >> >> It’s also not related to private symbols; this is already how
> >> >> >> >> properties
> >> >> >> >> work, regardless of what kind of key they have.
> >> >> >> >>
> >> >> >> >> > The difference here is that in your use cases, library A is
> >> >> >> >> > "sneakily"
> >> >> >> >> > storing information on object B.
> >> >> >> >>
> >> >> >> >> What use case are you referring to here? I can’t find any
> example
> >> >> >> >> in
> >> >> >> >> the
> >> >> >> >> previous posts that matches these descriptions. As Isiah said,
> >> >> >> >> “all
> >> >> >> >> of
> >> >> >> >> the
> >> >> >> >> examples here I've presented are for scenarios where the state
> is
> >> >> >> >> related to
> >> >> >> >> the factory that created the objects.” The same is true of my
> >> >> >> >> examples.
> >> >> >> >> Everybody’s on the same page regarding not wanting to add
> >> >> >> >> properties
> >> >> >> >> to
> >> >> >> >> objects their own libraries do not create.
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180803/f89eb467/attachment-0001.html>