!Re: proposal: Object Members

[Ranando King]

> 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/1897796c/attachment-0001.html>