!Re: proposal: Object Members

Darien Valentine valentinium at gmail.com
Sat Jul 28 17:49:14 UTC 2018

To put this another, much briefer way, here’s a hypothetical model for
associating private state with objects that would cover me. Privacy would
be provided...

1. in the form of symbolic keys whose presence cannot be observed (i.e.,
they would not be exposed by `getOwnPropertySymbols`)
2. and which have a syntactic declaration so that one can be sure they are
really getting private keys (i.e., an api like `Symbol.private()` wouldn’t

const bar = private();

// alternatively: const #bar; could be anything so long as it’s syntactic

class Foo {
  constructor() {
    this[bar] = 1;

// etc

The keys would be typeof 'symbol'; the only difference being that they are
symbols which are flagged as private when created. They would be permitted
only in syntactic property assignments and accesses. Existing reflection
utilities would disallow the use or appearance of such symbols both to
ensure privacy and to maintain the invariant that they are always simple
data properties:

Reflect.defineProperty({}, #bar, { ... }); // throws type error
Object.getOwnPropertyDescriptors(someObjWithAPrivateSlot); // does not
include it
foo[bar] = 2; // fine

This is significantly simpler than what’s in flight both in terms of syntax
and mechanics, which makes me suspicious that I’m probably ignoring things
that other people find important. However it would bring parity to ES
objects wrt being able to implement genuinely private slots in userland
with the same flexibility as what is done internally.

In total, this entails a new primary expression, a boolean flag associated
with symbol values, and an extra step added to several algorithms
associated with Object and Reflect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180728/d00dde23/attachment.html>

More information about the es-discuss mailing list