Runtime options

[John J Barton]

I'm trying to remove our global options in favor of options passed by argument. The remaining obstacles are two uses of global options in the runtime, to support alternative outputs for Symbol.toString() and Symbol.valueOf():

https://github.com/google/traceur-compiler/blob/master/src/runtime/runtime.js#L134

To me it seems like these uses are not vital: if these functions are called at all in code that does not use --symbol, then the return value has no constraint and may as well be the same as the result when --symbol is true.  (Changing this code is easy but we have a number of tests that would need to be fixed up).

I don't really see how this runtime option really works for any code other than Traceur itself. Outside of the command line or explicit calls to set options in user code, user code has no way of knowing what options were used to compile.  Of course we could invent some way, but we don't have it now.  

So: does anyone object if I remove the runtime option feature and its use in Symbol?

jjb

[Erik Arvidsson]

I'm in favor of removing this but it is not trivial.

The problem is that we want to support partial Symbol support even
when --symbol is not enabled (for iteration for example).

> --
> You received this message because you are subscribed to the Google Groups
> "traceur-compiler-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to traceur-compiler-d...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
erik

[John J Barton]

Are you saying that the Symbol.valueOf() and Symbol.toString() results when --symbol is *not* enabled is something we need to support?  Seems odd.

[Erik Arvidsson]

I don't think we need to support those any more. All our runtime code
uses toPropertyName to allow usage of symbols in member lookup
expressions.

On Mon, Jan 12, 2015 at 12:07 PM, John J Barton