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 [email protected] www.isiahmeadows.com On Mon, Jul 30, 2018 at 6:35 PM, Waldemar Horwat <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
