Feedback on the Relationship strawman

Tom Van Cutsem tomvc.be at gmail.com
Thu Apr 11 07:18:32 PDT 2013


2013/4/11 David Bruant <bruant.d at gmail.com>

>  It could be considered by authors to use syntax to differentiate when
> they do something public ([] and .) and something private (@). This visual
> distinction would only follow the trend of using _properties in JavaScript
> to denote something expected to be private; convention also used in Dart to
> denote privacy.
>
> I'm doubtful of the use of strings and symbols in the right-hand side.
>

There's something to be said for using the o at r syntax only for private
fields.


>
>  Under this proposal, a private field (aka private symbol) is simply a
> {Weak}Map. The @geti/@seti of a {Weak}Map will retrieve or store the
> binding like its get/set methods would.
>
>  Normal Objects cannot store Object->Object bindings, only String->Object
> bindings, so I don't see how the default @geti/@seti implementation on
> Object.prototype could do the same thing as those on {Weak}Map.prototype.
>
> By using a WeakMap under the hood. Trying to give a try of what I would
> expect; this is a functional definition using code, not a formal
> specification (especially when it comes to how storage is performed):
>

I think this is unnecessarily complicating the proposal. By defining a
standard Object.prototype[@geti] method that uses a WeakMap under the hood,
potentially every object now needs this hidden WeakMap storage.

The code you wrote seems a fine abstraction that can be provided by a
library.

As I wrote "Object.prototype[] = ", I realized that this is global
> authority that opens an undesired communication channels. If that's the
> case, another idea would be to be able to generate such @geti/@seti pairs
> (so that only parties with access to a given pair have access to the
> related storage). Per-class pairs could be generated to have per-class
> private properties, etc.
>

Let's first try to get consensus on what is already there before adding
more features.

Thanks for the feedback,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130411/d42e46a9/attachment.html>


More information about the es-discuss mailing list