On Mon, Jun 16, 2014 at 1:40 PM, Calvin Metcalf <[email protected]> wrote:
> > > A good question Rick, I sketched that out pretty quickly earlier today. > It did take me a while to remember that modules are the ONE place where > strings are by reference an not by value... > It's more than that—if I specify an export of a specific binding form (in this case `const`, whether it's a primitive string value or otherwise), then user code shouldn't be able to change the meaning. My const should only be a const, but your design has the surface appearance of permitting that const to become a let binding. Rick > On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron <[email protected]> > wrote: > >> >> >> >> On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf <[email protected] >> > wrote: >> >>> e.g. something like >>> https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7 >>> >> >> re: >> >> let { foo, bar } = import "library"; >> >> Ignoring the UnaryExpression ambiguity, what happens here: >> >> >> // library.js >> export const MAX_VALUE = 1023; >> >> >> // program.js >> let { MAX_VALUE } = import "library"; >> MAX_VALUE = 1; >> >> >> Rick >> >> >> >> >> >> >> >>> >>> On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian <[email protected] >>> > wrote: >>> >>>> On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf >>>> <[email protected]> wrote: >>>> > They curly braces only look like destructuring if you keep the name >>>> the >>>> > same, when imported with a different name it's a slightly different >>>> syntax, >>>> > {oldname as newname} not {oldname: newname}, also as it currently >>>> stands >>>> >>>> I wish that the authors of the module spec would accept that "object >>>> as module" is something JS authors have gotten used to. It's rather >>>> nice that we don't have to add another "module" type to our mental >>>> model. I understand that the spec authors want to insert some magic >>>> mechanisms so that cyclic dependencies "just work", but that shouldn't >>>> require us to invalidate our simple mental model for the common case. >>>> >>>> Using destructuring syntax for imports would be a *good thing*. It >>>> builds on our existing understanding of JS constructs, instead of >>>> adding more gratuitously different things to learn. >>>> >>>> Similarly, I like the proposal floated here on es-discuss that reuses >>>> the same syntax for "default exports", so that the user doesn't have >>>> to know whether the module author did a default export of an single >>>> object, or used exports of named functions. The syntax should help >>>> the developer by papering over these differences so that destructuring >>>> and uses were consistent. Sure, there would be some subtle >>>> differences under-the-covers regarding the type of the module object >>>> and how the destructuring assignment was implemented, but the syntax >>>> shouldn't make the user stumble over these. >>>> --scott >>>> >>> >>> >>> >>> -- >>> -Calvin W. Metcalf >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > > > -- > -Calvin W. Metcalf >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
