Exporting Symbols

Fri Oct 16 18:46:56 UTC 2015

The symbol registry is a great way to map universal (not just global, but
fully cross-realm) names (strings) to unique, distinct concepts (symbols).
But as a flat string namespace has all the same kinds of issues symbols
were introduced to solve. IIUC throwing `Math.random` strings into the
symbol registry is pretty much equivalent to writing (non-enumerable)
Math.random object properties on the global object, right? Doesn't this
eliminate any of the cross-realm dereferencing advantages provided by the
symbol registry?

I suspect we'll see the symbol registry used with something like xml's
namespace uris to address this -- fully qualified, canonical uris as a
means of unambiguously resolving the symbol for some fully-cross-realm
"concept", which might look something like `Symbol.for('
http://example.com/v5.4')` <http://example.com/v5.4')>.

This mitigates collisions naturally, and is reasonably legible -- though
I'm devs won't want to pepper these xmlns monstrosities throughout their
application code. ISTM library authors will end up providing something like
the `require(“our-symbols”).SpecialSymbol` module Fransisco suggested,
where string binding names, sensible in the context of some library, are
associated with these global fully-qualified registered symbols.

This might look `export let v5_4 = Symbol.for('http://example.com/v5.4')
}`. The url can be whatever you want (and like xmlns uris, need not be
resolvable). There are certainly better uri schemes for this that may be
more sensible -- you can use whatever you want, so long as you do it
consistently. This essentially transform the module import path namespace
into a kind of thesaurus to map strings which make sense in the context of
some module to some universal concept -- which could offer some pretty nice
wins when writing generic library code.

On Thu, Oct 15, 2015 at 4:28 PM, Rick Waldron <waldron.rick at gmail.com>
wrote:

> 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
>>>
>>
> _______________________________________________
> 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/20151016/29380946/attachment-0001.html>