Module Namespace Objects - "writable"
tj.crowder at farsightsoftware.com
Wed Oct 24 17:42:23 UTC 2018
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
> 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
So the most sensible thing was `writable: true` rather than `writable:
How'd I do? :-)
-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss