Oooh, I see. Fantastic, thank you Mark and Logan!
-- T.J. Crowder On Wed, Oct 24, 2018 at 7:03 PM Mark Miller <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
