!Re: proposal: Object Members
isiahmeadows at gmail.com
Mon Jul 30 23:35:51 UTC 2018
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
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.
contact at 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:
>> TL;DR: private symbols that proxies can't see and that can't be
> 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.
More information about the es-discuss