Private names use cases

[David-Sarah Hopwood]

On 2010-12-21 18:20, Allen Wirfs-Brock wrote:
> Even if this style did become the norm, I don't see why you would argue in
> support of mechanisms that allow extension of frozen objects.  Isn't the
> whole point of freezing to prevent any extensions.  why is the fact that
> the extension is accomplished using a side-channel any more acceptable to you.

That's straightforward: adding an association to an object in a side table
in no way breaks the encapsulation of that object. (If it did, then WeakMaps
or any simulation of them would also break encapsulation, which is not the
case.)

Note on terminology: a "side channel" is a channel by which sensitive
information is unintentionally leaked from some operation to potential
attackers. This has no relation to a "side table".

>> Note that I emphasized "properties" rather than a new concept such as "private fields".
>> I believe we should be trying to build upon the conceptual foundation of the existing
>> JavaScript object model whenever possible. We should strive to avoid introducing new
>> concepts such as non-property fields into the object model.  (see
>> http://www.wirfs-brock.com/allen/posts/43  for further thoughts on this topic.)
>>
>> I find this latter point and your elaboration on that web page bizarre. It is the
>> private names proposal that would change the object model, even if you consider
>> these changes minor. The soft fields proposal does not change the object model
>> at all. It has the semantics of a side table.
> 
> I am speaking of the object model, as perceived to by a JavaScript programmer of
> moderate skill and also by JavaScript implementors.

This is already problematic. The object model is defined by the spec, not by
what any particular programmer or implementor perceives.

Soft fields would not extend the object model as defined by the spec at all.
That is an objective statement independent of anyone's perceptions.

What a JavaScript programmer of moderate skill will perceive depends on
how the feature is explained to them. A good explanation will say both that
soft field slots can be viewed as entries in a side table, and that they can
be viewed as being stored "with" the key object (and that the latter is
likely to be closer to the truth in an optimized implementation, modulo any
pointer indirections).

(A minority -- but an important minority -- of programmers will read the spec
itself, which will give the side table view normatively, and the other view
in a nonnormative NOTE. Other programmers will read interpretations of the
spec. Writers of such interpretations will not be able to miss that there
are two views; it is possible that they will oversimplify or give bad
explanations, but there is not much we can do about that, other than comment
on them.)

JS implementors can also be expected to know both views and translate between
them as necessary.

> To me, an incremental extension of a concept that is already present (extending
> the set of values that can be used as a property name) is a much smaller
> extension to the object model than the introduction of a new form of per
> object state (whether called a private field, a soft field, or something else).

It can be viewed as a form of per-object state, but it's not anything
fundamentally "new" that could not be implemented (perhaps inefficiently) in
ES5 + WeakMap, or even just ES5.

> The fact that you are proposing implementing you object extension as a look-aside
> table

But that is completely backwards! Mark is proposing to *specify* the extension
that way. Specifications do not dictate implementation.

> doesn't mean it isn't a conceptual extension to the object model perceived by
> JavaScript programmers.

The soft field abstraction is a library feature.

This library feature may, if we decide to do so, be supported by syntax.

The syntax may be what is currently proposed in the private names proposal,
or something else.

The syntax proposed in the private names proposal requires extensions to
the object model.

Clearly, this does not imply that the soft field abstraction by itself
requires extensions to the object model. The combination of the soft field
abstraction and the private names syntax does, because the private names
syntax does by itself.

> That might arguably be the case if you were simply defining a set of conventions
> based upon Ephemeron tables for decorating objects with additional non-encapsulated
> state.  However, as soon as you tie into either the language's property access syntax
> ( . and []) as you have (perhaps reluctantly) proposed you have extended the
> conceptual object model.

Mark has criticized that syntax partly because it depends on extending the
object model, and so have I. I intend to propose an alternative syntax, but
I'll do that in another post/thread.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101222/62982fc0/attachment-0001.bin>