Symbol has built-in API for making Symbols available across all code realms:
http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.for http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.keyfor You can create a generated key and export it, giving your consumers only the key, which they can then use to get the symbol. // In module.js let key = Math.trunc((Math.random() * 0xffffffff)); let sym = Symbol.for(key); // use sym throughout the module code export { key as features } // In program.js import { features } from "module"; console.log(features, Symbol.for(features)); Rick On Thu, Oct 15, 2015 at 3:38 PM Alexander Jones <a...@weej.com> wrote: > Unless of course you needed to export a "features" AND support this magic > symbol. > > On Thursday, 15 October 2015, Ron Buckton <ron.buck...@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-boun...@mozilla.org] *On Behalf Of >> *Francisco Tolmasky >> *Sent:* Thursday, October 15, 2015 10:47 AM >> *To:* Logan Smyth <loganfsm...@gmail.com> >> *Cc:* es-discuss@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 <loganfsm...@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 <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 >> <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> >> tolma...@gmail.com >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@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> >> 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
