Module Namespace Objects - "writable"

T.J. Crowder tj.crowder at farsightsoftware.com
Wed Oct 24 18:11:17 UTC 2018


Oooh, I see.

Fantastic, thank you Mark and Logan!

-- T.J. Crowder

On Wed, Oct 24, 2018 at 7:03 PM Mark Miller <erights at gmail.com> wrote:

> Ah. Crossed in the mail. Yes, Alan raises the same issues regarding the
> TDZ vs non-writable worry.
>
> Thanks for the pointer.
>
> On Wed, Oct 24, 2018 at 11:01 AM Logan Smyth <loganfsmyth at gmail.com>
> wrote:
>
>> Here's one other post about this from Allen:
>> https://github.com/tc39/ecma262/issues/749#issuecomment-265637923
>>
>> 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
>>>
>> _______________________________________________
>> 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/7f7e8b6c/attachment.html>


More information about the es-discuss mailing list