!Re: proposal: Object Members

[Isiah Meadows]

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