New private names proposal

David-Sarah Hopwood david-sarah at
Thu Dec 16 21:11:05 PST 2010

On 2010-12-17 01:24, David Herman wrote:
> Mark Miller wrote:
>> Ok, I open it for discussion. Given soft fields, why do we need private
>> names?
> I believe that the syntax is a big part of the private names proposal. It's
> key to the usability: in my view, the proposal adds 1) a new abstraction to
> the object model for private property keys and 2) a new declarative
> abstraction to the surface language for creating these properties.

I don't like the private names syntax. I think it obscures more than it
helps usability, and losing the x["id"] === equivalence is a significant

As Mark points out, though, that syntax can be supported with either
proposal. The private names proposal is more entangled with syntactic
changes, but that's a bug, not a feature.

> In fairness, I think the apples-to-apples comparison you can make between
> the two proposals is the object model. On that score, I think the private
> names approach is simpler: it just starts where it wants to end up (private
> names are in the object, with an encapsulated key), whereas the soft fields
> approach takes a circuitous route to get there (soft fields are
> semantically a side table, specified via reference implementation, but
> optimizable by storing in the object).

The private names approach is not simpler. It's strictly more complicated for
the same functionality. You can see that just by comparing the two proposals:
the specification consists entirely of the given code for the SoftField
abstraction. In practice you'd also add a bit of non-normative rationale
concerning how soft fields can be efficiently implemented, but that's it.

In (even
exlcuding the syntactic changes, to give a fairer comparison), we can see
a very significant amount of additional language mechanism, including:

 - a new primitive type, with behaviour distinct from any other type.
   This requires changes, not just to 'typeof' as the strawman page
   acknowledges, but to every other abstract operation in the spec that
   can take an arbitrary value. (Defining these values to be objects
   would simplify this to some extent, but if you look at how much
   verbiage each [Class] of objects takes to specify in ES5, possibly
   not by much.)

 - quite extensive changes to the behaviour of property lookup and
   EnvironmentRecords. (The strawman is quite naive in suggesting that
   only 11.2.1 step 6 needs to be changed here.)

 - changes to [[Put]] (for arrays and other objects) and to object literal
   initialization; also checking of all uses of [[DefineOwnProperty]] that
   can bypass [[Put]].

 - changes to a large number of APIs on Object.prototype and Object,
   the 'in' operator, JSON.stringify, and probably others.

None of these additional mechanisms and spec changes are needed in the
soft field approach.

In addition, the proposal acknowledges that it only provides weak
encapsulation, because of reflective operations accessing private
properties. It justifies this in terms of the utility of "monkey patching",
but this seems like a weak argument; it is not at all clear that monkey
patching of private properties is needed. Scripts that did that would
necessarily be violating abstraction boundaries and depending on
implementation details of the code they are patching, which tends to
create forward-compatibility problems. (This is sometimes true of scripts
that monkey-patch public properties. I'm not a fan of monkey patching in
general, but I think it is particularly problematic for private properties.)

There is some handwaving about the possibility of sandboxing environments
being able to work around this deficiency, but the details have not been
thought through; in practice I suspect this would be difficult and error-

In general, I disagree with the premise that the best way to *specify* a
language feature is to "start where it wants to end up", i.e. to directly
specify the programmer's view of it. Of course the programmer's view needs
to be considered in the design, but as far as specification is concerned,
if a high-level feature cannot be specified by a fairly simple desugaring
to lower-level features, then it's probably not a good feature.

David-Sarah Hopwood  ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the es-discuss mailing list