!Re: proposal: Object Members

[Darien Valentine]

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
work)

```
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:

```js
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>