!Re: proposal: Object Members

Fri Aug 3 19:36:29 UTC 2018

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