!Re: proposal: Object Members

[Jordan Harband]

Note that builtins with internal slots, like Map, Set, and Promise, are
still mutable after being frozen - so if one is trying to model internal
slots with some kind of property stored on the object, then freezing *must*
have no effect on the ability to alter their contents.

On Tue, Jul 31, 2018 at 2:34 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180731/e7eb4738/attachment.html>