Exporting Symbols

[Ron Buckton]

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] On Behalf Of Francisco Tolmasky
Sent: Thursday, October 15, 2015 10:47 AM
To: Logan Smyth <loganfsmyth at gmail.com>
Cc: 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<mailto: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<mailto: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<mailto:tolmasky at gmail.com>

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto: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<mailto:tolmasky at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151015/fcffaa51/attachment-0001.html>