The main issue is that modules are statically analysable and
imports/exports are processed before the module executes, and the behavior
of a symbol is by definition a runtime thing. Until the code executes,
there would be no symbol object, and there would be no way to know what
thing was being imported imported / exported.
The primary benefit of symbols is that they are unique, and cannot collide
unless you have a reference to them. Module exports have full control over
their names and don't have the same collision issues that objects and
classes generally do. What is the benefit you are hoping to get from
exposing these values on symbols instead of string keys?
On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky <tolma...@gmail.com>
wrote:
> Not sure if it isn’t the case, but it seems the only way to export symbols
> right now is:
>
> ```js
> export default { [Symbol(“something”)]: blah }
> ```
>
> It would be nice if “symbol literals” could somehow be supported. In
> particular, I can imagine this sort of thing becoming common:
>
> export { “5.4” as Symbol(“version”) }
>
> Or, even better (but harder since its now more expression):
>
> import VersionSymbol from “symbols"
> export { “5.4” as VersionSymbol }
>
> I’m currently writing an API where there are expected methods stored in
> symbols, but this forces exporting one default object instead of being able
> to lay them out individual.
>
> Thanks,
>
> Francisco
>
> --
> Francisco Tolmasky
> www.tolmasky.com
> tolma...@gmail.com
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
