!Re: proposal: Object Members

[Ranando King]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180801/db00c967/attachment.html>