Exporting Symbols

Alexander Jones alex at weej.com
Thu Oct 15 19:38:29 UTC 2015


Unless of course you needed to export a "features" AND support this magic
symbol.

On Thursday, 15 October 2015, Ron Buckton <Ron.Buckton at microsoft.com> wrote:

> Wouldn’t this work?
>
>
>
> our-symbols.js:
>
> ```js
>
> export const SpecialSymbol = Symbol("SpecialSymbol");
>
> ```
>
>
>
> their-consumer.js
>
> ```js
>
> import { SpecialSymbol } from "our-symbols";
>
>
>
> export const features = {
>
> [SpecialSymbol]: true
>
> };
>
> ```
>
>
>
> our-features.js
>
> ```js
>
> import { SpecialSymbol } from "our-symbols";
>
> import { features } from "their-consumer";
>
>
>
> if (features[SpecialSymbol]) {
>
>   // …
>
> }
>
> ```
>
>
>
> This uses an export named “features”, though in practice it’s pretty much
> the same as using “export default”. While the “features” identifier could
> theoretically be some other “features” with a different meaning, you can
> still detect the presence of your special symbol.
>
>
>
> Ron
>
>
>
> *From:* es-discuss [mailto:es-discuss-bounces at mozilla.org
> <javascript:_e(%7B%7D,'cvml','es-discuss-bounces at mozilla.org');>] *On
> Behalf Of *Francisco Tolmasky
> *Sent:* Thursday, October 15, 2015 10:47 AM
> *To:* Logan Smyth <loganfsmyth at gmail.com
> <javascript:_e(%7B%7D,'cvml','loganfsmyth at gmail.com');>>
> *Cc:* es-discuss at mozilla.org
> <javascript:_e(%7B%7D,'cvml','es-discuss at mozilla.org');>
> *Subject:* Re: Exporting Symbols
>
>
>
> There are special features we want to expose if a module defines a certain
> key. However, we’d like to not rely on certain names just because there’s
> some chance they came up with it themselves. If it was a symbol that we
> gave them access to, it would be impossible for this to be the case, they
> would have had to grab the symbol from us:
>
>
>
> var SpecialSymbol = require(“our-symbols”).SpecialSymbol;
>
>
>
> export { whatever as SpecialSymbol }
>
>
>
> The difficulty I’m having right now is being torn by two competing “best
> practices”: on the one hand, you can’t do what I did above for the runtime
> reasons, on the other hand you CAN actually pull it off using the export
> default strategy, and in that situation it technically is safer for us to
> use our special symbol instead of relying on a string match.
>
>
>
>
>
> On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth <loganfsmyth at gmail.com
> <javascript:_e(%7B%7D,'cvml','loganfsmyth at gmail.com');>> wrote:
>
> 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 <tolmasky at gmail.com
> <javascript:_e(%7B%7D,'cvml','tolmasky at 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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.tolmasky.com&data=01%7c01%7cron.buckton%40microsoft.com%7c2e02643e0d944134b1f708d2d588b34b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2IQQvQqHc7DJeuLKj9fgCknBXv7p56Vct6%2bSNKqL2N8%3d>
> tolmasky at gmail.com <javascript:_e(%7B%7D,'cvml','tolmasky at gmail.com');>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> <javascript:_e(%7B%7D,'cvml','es-discuss at mozilla.org');>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c2e02643e0d944134b1f708d2d588b34b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qb3AoRW3sNrU4Fi9l4Jqxcc%2fC%2b7WRRLO7JoeGQ6y1DE%3d>
>
>
>
>
>
>
>
> --
>
> Francisco Tolmasky
> www.tolmasky.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.tolmasky.com&data=01%7c01%7cron.buckton%40microsoft.com%7c2e02643e0d944134b1f708d2d588b34b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2IQQvQqHc7DJeuLKj9fgCknBXv7p56Vct6%2bSNKqL2N8%3d>
> tolmasky at gmail.com <javascript:_e(%7B%7D,'cvml','tolmasky at gmail.com');>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151015/85fa0a4e/attachment.html>


More information about the es-discuss mailing list