Exporting Symbols

Thu Oct 15 20:28:27 UTC 2015

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 <waldron.rick at gmail.com> 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 <alex at 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.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] *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>
>>> 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>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> 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
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151015/4d49f754/attachment-0001.html>