!Re: proposal: Object Members

[Isiah Meadows]

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.