those {} that you see in the export and import statements are not objects, it
is just syntax. Yes, I know, people confuse them with objects, until they
realize they aren’t. We probably should have chosen a different syntax to
signal that it is a binding from the module’s environment record.
Another way to look at this is from the lenses of function declarations or
function expressions, those {} that represent the body of the function are more
closely related to what you use in the import/export statements that what you
use for objects.
For those assuming that this will just fly through the staging process, it will
not! There are many issues when considering it a object declaration.
/caridy
> On Dec 13, 2017, at 2:07 PM, dante federici <[email protected]>
> wrote:
>
> Definitely make a proposal for this -- I'm pretty tired of colliding utility
> function names and having to aggressively namespace them.
>
> It's been said but I want to just throw in another voice that this will 100%
> work with tree shaking, and as we get better at organizing our modules and
> dependencies, it'll become more apparent.
>
> With all the pushes toward pure functional code, utility modules and
> libraries will benefit more and more from tree shaking and clear / strong
> import/export syntax.
> _______________________________________________
> 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
