The math.trunc part is completely irrelevant, leftover from fiddling around—sorry for the noise!
On Thu, Oct 15, 2015 at 4:13 PM Rick Waldron <[email protected]> wrote: > 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 <[email protected]> wrote: > >> Unless of course you needed to export a "features" AND support this magic >> symbol. >> >> On Thursday, 15 October 2015, Ron Buckton <[email protected]> >> 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:[email protected]] *On Behalf >>> Of *Francisco Tolmasky >>> *Sent:* Thursday, October 15, 2015 10:47 AM >>> *To:* Logan Smyth <[email protected]> >>> *Cc:* [email protected] >>> *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 <[email protected]> >>> 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 <[email protected]> >>> 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> >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> 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> >>> [email protected] >>> >> _______________________________________________ >> 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
