Module Namespace Objects - "writable"

Mark Miller erights at gmail.com
Wed Oct 24 18:01:52 UTC 2018


Extremely good!

But it is more than just a "should" or "sensible". It is a requirement of
the object invariants. If a property is described as a non-configurable
non-writable data property, it must always have the same value.

One issue I think should be open to debate: If the exported variable is
declared const, do we follow the principle you mention:

> 2. Whether or not they're writable by the exporting module isn't
information that should leak out of it

or do we consider the exporting module to be exporting its const-ness as
well? If the latter, then those properties probably should be described as
non-writable non-configurable data properties with, therefore, a stable
value.

However, I say "probably" above because of one issue that gives me pause:
the temporal dead zone. It does *not* violate the invariants for a [[Get]]
or [[GetOwnPropertyDescriptor]] on a non-writable non-configurable data
property to intermittently fail with a thrown error. The stability
guarantee is only regarding what the non-failure cases report. But it is
weird to report that a property is a non-writable non-configurable data
property with a stable value before that value is determined. Worse, given
how the object invariants are enforced on proxies (with the shadow target
bookkeeping), I don't see how a proxy could emulate this behavior. This is
in some sense a flaw in the proxy design: This shows an exotic object
behavior that *is* allowed by the object invariants but not emulatable by
proxies.






On Wed, Oct 24, 2018 at 10:42 AM T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> I'm curious if I've inferred the rationale for something correctly.
>
> The module namespace object properties for exports have `writable: true`
> in their property descriptors, but of course, they aren't writable (the
> module namespace object has its own [[Set]] implementation that returns
> false). I wondered why they weren't `writable: false`, so I went looking.
>
> I found discussion in the March 24 2015 meeting notes about whether to
> even have `getOwnPropertyDescriptor` work. The consensus was yes, it should
> work (mixins!), and that it should report a basic data property that isn't
> configurable -- but is writable. Yahuda Katz points out that:
>
> > it is writable, but it's not writable by you
>
> though that's not always true (it may be declared `const`; that
> information isn't leaked from the module, though).
>
> In the May 25 2017 notes I found a comment from Mark S. Miller in relation
> to `writable: true`:
>
> > Non-writeable provides guarantee. Writable provides no guarantee.
>
> And this exchange between Yahuda Katz, Allen Wirfs-Brock, and Adam Klein:
>
> > YK: There is a a new property that we define as writable that is not
> writable.
> >
> > AWB: Not new.
> >
> > AK: Since... Proxys!
>
> There was some discussion of considering some flag basically saying what
> YK said, e.g., it's writable, but not by you :-) -- but that was more a
> brief digression that didn't go anywhere.
>
> So, then, what I infer is: They're marked writable because:
>
> 1. They may be writable by the exporting module, so code can't assume the
> value won't change; `writable: false` would make that assumption valid
> 2. Whether or not they're writable by the exporting module isn't
> information that should leak out of it
> 3. Non-writable `writable: true` data properties were already a thing
> (Proxies)
>
> So the most sensible thing was `writable: true` rather than `writable:
> false`.
>
> How'd I do? :-)
>
> -- T.J. Crowder
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181024/62f8a2bc/attachment-0001.html>


More information about the es-discuss mailing list