Re: Module Comments
> Since it is just sugar, and supposed to be equivalent to the > expansion, you (fortunately) would get an error (statically). > OK, then suppose we have these two separate forms: import x from "url"; // Bind x to the anonymous export, if defined, otherwise error and import module x from "url"; // Bind x to the module instance In the vast majority of cases the "module" keyword above can be inferred correctly at link-time based on whether or not there is an anonymous export in the target module. If it were important for the user to disambiguate in those rare cases, and load the module instance instead of the anonymous export, then she could simply provide the optional "module" keyword. Does that work? - Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module Comments
Domenic Denicola wrote:
-Original Message-
From: Andreas Rossberg [mailto:rossb...@google.com]
Sent: Thursday, December 6, 2012 11:31
On 6 December 2012 16:44, Domenic Denicola
wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com/1ab3f0daa7b37859ce43
I would *really* appreciate if people read it (it's easy reading, I
promise!) and incorporated some of our concerns and ideas into their
thinking on module syntax.
However, the more radical parts of your proposal (allowing arbitrary export
expressions, and arbitrary import patterns) do not work.
The problem is that imports are not normal variable assignments. They do not
copy values, like normal destructuring, they are aliasing bindings! If you were
to allow arbitrary expressions and patterns, then this would imply aliasing of
arbitrary object properties. Not only is this a completely new feature, it also
is rather questionable -- the aliased location might disappear, because objects
are mutable.
Thanks for the feedback Andreas; this is really helpful. It took me a while to
figure out what you meant by this, but I think I understand now. However, I
think that since the bindings are const bindings, the difference between
copying and aliasing is unobservable—is that right? Thus the mental model could
be copying in all cases, both top-level and deeper.
I think the symmetry I am looking for is that
import { x: [a, b], f } from "foo";
should work the same as
import foo from "foo";
const { x: [a, b], f } = foo;
No, afaicr that was not the idea, see below.
And I realize the linked gist does not introduce const bindings, but instead
let bindings; that's easy enough to fix if it's the right path forward.
You could also consider imports always meaning copying, but then you exporting
a variable will no longer be useful.
This is the part that made me question whether I understand what you're saying. What do you mean by
"exporting a variable" and "useful"?
The part about "exporting a variable" is in fact explaining that it is
not about const as you noted above (cp in unix PoV), but really copy of
the binding (ln in unix PoV).
That is, when you in "foo"
export let FOO = 42;
and do
import { foo } from "foo";
in two places, then "foo = -1;" in one place means it is -1 in all other
places as well.
I am right in what Andreas meant, then it leads me to the question: is
it really meant to be that way? Isn't copying the value (used all over
in the language) better way? If I want a shareable value, I export an
object that has it as a property. Should export and import be by-reference?
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: new snd super running different code, proposal to fix.
Hello,
I am doing a little fix in my proposal, [[GetOwn]] was too nannyish,
[[Get]] is right.
Herby Vojčík wrote:
So the [[Construct]] should look like this:
1) Let creator be Foo.[[Get]](@@create)
2) Let newObj be creator.call(foo). //Foo is passed as the this value to
@@create
3) Let proto be Foo.[[Get]]("prototype")
4) Fail if problem.
5) If there is [[ProperClass]] in proto, then
5.1) Let ctor be proto.[[GetOwn]]("constructor")
5.1) Let ctor by proto.[[Get]]("constructor")
5.2) Throw "Not constructible" if not present.
6) Else
6.1) Let ctor be Foo
7) Let ctorResult be ctor.[[call]](newObj,args)
8) If Type(ctorResult) is Object, return ctorResult
9) else return newObj
When someone consciously deletes "constructor" from [[ProperClass]], it
is ok and he is thus consciously saying "just do the inherited one".
Which is really great feature! With this proposal, there is no real need
to generate default constructors, they are included for free (simply do
not include "constructor" in [[ProperClass]] and inherited one will be
used). I see this as sign that this proposal of "new" semantic is on the
right track.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Module Comments
Yeah, that makes sense. I agree. Thanks.
Nathan
>
> On 9 December 2012 15:04, Nathan Wall wrote:
> >> The problem is that imports are not normal variable assignments. They
> >> do not copy values, like normal destructuring, they are aliasing
> >> bindings! If you were to allow arbitrary expressions and patterns,
> >> then this would imply aliasing of arbitrary object properties. Not
> >> only is this a completely new feature, it also is rather questionable
> >> -- the aliased location might disappear, because objects are mutable.
> >
> > Could it be structured so that using `export` directly on a variable
> > exported the alias, while using `import { x: [ a, b ] } from A; ` was
> > basically just sugar for `import { x } from A; let [ a, b ] = x;` so that a
> > and b copied not aliased?
>
> That's what I referred to when I wrote:
>
> > You could arguably make this saner by interpreting nested patterns in
> > an import as copying, not aliasing, but I think mixing meanings like
> > that would be rather confusing and surprising.
>
> So yes, you could do that, but no, I don't think it is a good idea.
> Your example:
>
> > import { x: { a, b }, f } from A;
> > f();
> > print(a); // 1
> > print(b); // 2
> >
> > ...
> >
> > import { x, f } from A;
> > f();
> > print(x.a); // 3
> > print(x.b); // 4
>
> demonstrates perfectly how it violates the principle of least surprise
> and can potentially lead to subtle bugs, especially when refactoring.
> One overarching principle of destructuring should be that all
> variables in one binding are treated consistently.
>
> /Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module Comments
On 9 December 2012 15:04, Nathan Wall wrote:
>> The problem is that imports are not normal variable assignments. They
>> do not copy values, like normal destructuring, they are aliasing
>> bindings! If you were to allow arbitrary expressions and patterns,
>> then this would imply aliasing of arbitrary object properties. Not
>> only is this a completely new feature, it also is rather questionable
>> -- the aliased location might disappear, because objects are mutable.
>
> Could it be structured so that using `export` directly on a variable
> exported the alias, while using `import { x: [ a, b ] } from A; ` was
> basically just sugar for `import { x } from A; let [ a, b ] = x;` so that a
> and b copied not aliased?
That's what I referred to when I wrote:
> You could arguably make this saner by interpreting nested patterns in
> an import as copying, not aliasing, but I think mixing meanings like
> that would be rather confusing and surprising.
So yes, you could do that, but no, I don't think it is a good idea.
Your example:
> import { x: { a, b }, f } from A;
> f();
> print(a); // 1
> print(b); // 2
>
> ...
>
> import { x, f } from A;
> f();
> print(x.a); // 3
> print(x.b); // 4
demonstrates perfectly how it violates the principle of least surprise
and can potentially lead to subtle bugs, especially when refactoring.
One overarching principle of destructuring should be that all
variables in one binding are treated consistently.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Module Comments
I see my previous email did not format well in the archive. I'm retrying this.
(Could someone please give me some formatting tips?)
Nathan
> The problem is that imports are not normal variable assignments. They
> do not copy values, like normal destructuring, they are aliasing
> bindings! If you were to allow arbitrary expressions and patterns,
> then this would imply aliasing of arbitrary object properties. Not
> only is this a completely new feature, it also is rather questionable
> -- the aliased location might disappear, because objects are mutable.
Could it be structured so that using `export` directly on a variable exported
the alias, while using `import { x: [ a, b ] } from A; ` was basically just
sugar for `import { x } from A; let [ a, b ] = x;` so that a and b copied not
aliased?
Example:
module A {export let x = { a: 1, b: 2 };export function f()
{ x = { a: 3, b: 4 }; };}
...
import { x: { a, b }, f } from A;f();print(a); // 1print(b); //
2
...
import { x, f } from A;f();print(x.a); // 3print(x.b); // 4
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Module Comments
> The problem is that imports are not normal variable assignments. They
> do not copy values, like normal destructuring, they are aliasing
> bindings! If you were to allow arbitrary expressions and patterns,
> then this would imply aliasing of arbitrary object properties. Not
> only is this a completely new feature, it also is rather questionable
> -- the aliased location might disappear, because objects are mutable.
Could it be structured so that using `export` directly on a variable exported
the alias, while using `import { x: [ a, b ] } from A; ` was basically just
sugar for `import { x } from A; let [ a, b ] = x;` so that a and b copied not
aliased? Example: module A {export let x = { a: 1, b: 2 };
export function f() { x = { a: 3, b: 4 }; };} ... import { x: { a,
b }, f } from A;f();print(a); // 1print(b); // 2 ... import
{ x, f } from A;f();print(x.a); // 3print(x.b); // 4
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module Comments
On 9 December 2012 03:51, Domenic Denicola wrote:
>> From: Andreas Rossberg [mailto:rossb...@google.com]
>> On 6 December 2012 16:44, Domenic Denicola
>> wrote:
>> > For the record, here's the idea Yehuda and I worked out:
>> >
>> > https://gist.github.com/1ab3f0daa7b37859ce43
>> >
>> > I would *really* appreciate if people read it (it's easy reading, I
>> > promise!) and incorporated some of our concerns and ideas into their
>> > thinking on module syntax.
>>
>> However, the more radical parts of your proposal (allowing arbitrary export
>> expressions, and arbitrary import patterns) do not work.
>>
>> The problem is that imports are not normal variable assignments. They do not
>> copy values, like normal destructuring, they are aliasing bindings! If you
>> were to allow arbitrary expressions and patterns, then this would imply
>> aliasing of arbitrary object properties. Not only is this a completely new
>> feature, it also is rather questionable -- the aliased location might
>> disappear, because objects are mutable.
>
> Thanks for the feedback Andreas; this is really helpful. It took me a while
> to figure out what you meant by this, but I think I understand now. However,
> I think that since the bindings are const bindings, the difference between
> copying and aliasing is unobservable—is that right?
No, because what you are aliasing isn't const. Consider:
module A {
export let x = 4
export function f() { x = 5 }
}
import {x, f} from A
f()
print(x) // 5
Moreover, it is still up in the air whether exported mutable bindings
should be mutable externally or not. V8, for example, currently allows
that, and although it doesn't implement 'import' yet you can access
the module directly:
A.x = 6
print(A.x) // 6
That is the natural behaviour if you want to be able to use modules as
a name spacing mechanism. Same in TypeScript, by the way.
>> You could also consider imports always meaning copying, but then you
>> exporting a variable will no longer be useful.
>
> This is the part that made me question whether I understand what you're
> saying. What do you mean by "exporting a variable" and "useful"?
I hope the example(s) clarify it. :)
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module Comments
On 9 December 2012 02:10, Kevin Smith wrote: > > So if you didn't set the anonymous binding in some module "x.js", what would > this do: > > import x from "x.js"; > > Would x be bound to the module instance or would we get a binding error? Since it is just sugar, and supposed to be equivalent to the expansion, you (fortunately) would get an error (statically). /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
