Re: Exporting Symbols

2015-10-17 Thread Isiah Meadows
May I ask what the use case for exporting symbol-named values is? I can't seem to think of any obvious one. On Fri, Oct 16, 2015 at 5:29 PM, Dean Landolt wrote: > [snip] > >> >> So if you export an opaque identity that you created yourself, and don't >> expose some

Re: Exporting Symbols

2015-10-16 Thread Dean Landolt
gt;> >>>> ```js >>>> >>>> import { SpecialSymbol } from "our-symbols"; >>>> >>>> import { features } from "their-consumer"; >>>> >>>> >>>> >>>> if (features[SpecialSymbo

Re: Exporting Symbols

2015-10-16 Thread Dean Landolt
[snip] > So if you export an opaque identity that you created yourself, and don't > expose some mechanism for downstream consumers to know what it means, > you're handing a bag of meaningless tokens which are, by definition, > completely useless to them. > I should add: if you only intend to

Re: Exporting Symbols

2015-10-16 Thread Dean Landolt
On Fri, Oct 16, 2015 at 3:46 PM, Rick Waldron wrote: > > > On Fri, Oct 16, 2015 at 2:47 PM Dean Landolt wrote: > >> The symbol registry is a great way to map universal (not just global, but >> fully cross-realm) names (strings) to unique, distinct

Re: Exporting Symbols

2015-10-16 Thread Rick Waldron
On Fri, Oct 16, 2015 at 2:47 PM Dean Landolt wrote: > 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

Exporting Symbols

2015-10-15 Thread Francisco Tolmasky
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

Re: Exporting Symbols

2015-10-15 Thread Logan Smyth
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

Re: Exporting Symbols

2015-10-15 Thread Rick Waldron
ures } from "their-consumer"; >>> >>> >>> >>> if (features[SpecialSymbol]) { >>> >>> // … >>> >>> } >>> >>> ``` >>> >>> >>> >>> This uses an export named “fe

Re: Exporting Symbols

2015-10-15 Thread Rick Waldron
> >> 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

Re: Exporting Symbols

2015-10-15 Thread Alexander Jones
rom:* es-discuss [mailto:es-discuss-boun...@mozilla.org > <javascript:_e(%7B%7D,'cvml','es-discuss-boun...@mozilla.org');>] *On > Behalf Of *Francisco Tolmasky > *Sent:* Thursday, October 15, 2015 10:47 AM > *To:* Logan Smyth <loganfsm...@gmail.com > <javascript:_e(%7B%7D,'cvml

RE: Exporting Symbols

2015-10-15 Thread Ron Buckton
ther “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-disc

Re: Exporting Symbols

2015-10-15 Thread Francisco Tolmasky
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