!Re: proposal: Object Members

[Isiah Meadows]

That is one supported use case, yes. But that isn't the only use case
this supports. It can still extend to traditional private class data,
too.

-----

Isiah Meadows
contact at isiahmeadows.com
www.isiahmeadows.com


On Mon, Jul 30, 2018 at 8:04 PM, Ranando King <kingmph at gmail.com> wrote:
> So you're wanting the ability for a 3rd-party function to be able to store
> data private to that library on an object it didn't create, and that only
> that library can access?
>
> On Mon, Jul 30, 2018 at 6:36 PM Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>>
>> First, my private symbols are properly *private*. The only
>> "unexpected" thing that could happen is making an object larger
>> memory-wise, which engines already have to be equipped to handle now
>> (libraries aren't always well-behaved, and like to occasionally add
>> expando properties to builtins and DOM elements). About the only thing
>> most people would care about is in the debugger.
>>
>> Second, I had things like this in mind with supporting expando
>> properties:
>> https://github.com/nodejs/node/blob/ae4fde8bc883686def5badfb324236320669e8f4/lib/internal/linkedlist.js
>>
>> In that case, the Node.js people made it a pseudo-mixin rather than an
>> actual type for performance reasons - there's fewer object allocations
>> and they needed that.
>>
>> So I've considered the expando problem, and I disagree about it being
>> a problem at all.
>>
>> -----
>>
>> Isiah Meadows
>> contact at isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Mon, Jul 30, 2018 at 6:35 PM, Waldemar Horwat <waldemar at google.com>
>> wrote:
>> > On 07/29/2018 04:37 PM, Isiah Meadows wrote:
>> >>
>> >> BTW, I came up with an alternate proposal for privacy altogether:
>> >> https://github.com/tc39/proposal-class-fields/issues/115
>> >>
>> >> TL;DR: private symbols that proxies can't see and that can't be
>> >> enumerated.
>> >
>> >
>> > Aside from syntax, the main semantic difference I see between this
>> > alternative and the main one is that this alternative defines private
>> > fields
>> > as expandos, creating opportunities for mischief by attaching them to
>> > unexpected objects.  Aside from privacy, one of the things the private
>> > fields proposal gives you is consistency among multiple private fields
>> > on
>> > the same object.  In the rare cases where you don't want that, you could
>> > use
>> > weak maps.
>> >
>> >     Waldemar
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss