Converting strings to template strings

2015-03-22 Thread KOLANICH
I needed a functionality but haven't found it. See https://stackoverflow.com/questions/29182244/convert-a-string-to-a-template-string for more details. I think that this should be included into standard; Also we need a standard format string functionality like

Re: Converting strings to template strings

2015-03-22 Thread Andrea Giammarchi
There's no such functionality indeed but you might want to have a look at this gist: https://gist.github.com/WebReflection/8f227532143e63649804 It gives you the ability to write `'test1 ${1 + 2} test2 ${3 + 4}' .template();` and read `test1 3 test2 7` or to pass an object similar to .Net

RE: Supporting feature tests directly

2015-03-22 Thread Gary Guo
So why not just add a sandbox, and let uncertificated codes run in the sandbox, providing the external environment means to catch error (or interact somehow) ___ es-discuss mailing list es-discuss@mozilla.org

Re: Supporting feature tests directly

2015-03-22 Thread Andrea Giammarchi
+1 to Kyle proposal, using eval or Function is not even an option in CSP constrained environments ( unless the relative code is provided as SHA256, then we need to agree on how such code should look like and share it as polyfill ) I'd also suggest `Reflect.isValidSyntax` as alternative to

RE: Supporting feature tests directly

2015-03-22 Thread Mark S. Miller
The combination of the loader and realm APIs should give us that and, of course, more. On Mar 22, 2015 8:52 AM, Gary Guo nbdd0...@hotmail.com wrote: So why not just add a sandbox, and let uncertificated codes run in the sandbox, providing the external environment means to catch error (or

Re: Converting strings to template strings

2015-03-22 Thread Mark S. Miller
On Sun, Mar 22, 2015 at 6:46 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: There's no such functionality indeed but you might want to have a look at this gist: https://gist.github.com/WebReflection/8f227532143e63649804 It gives you the ability to write `'test1 ${1 + 2} test2 ${3 +

Re: Converting strings to template strings

2015-03-22 Thread Andrea Giammarchi
the snippet is extremely simplified and just works for 99.9% of cases it's meant to be used, a way to provide properties via objects within a string used as template. The string should not be parsed in the wild, same you won't evaluate ever string templates without knowing the source. Of course if

Re: Converting strings to template strings

2015-03-22 Thread Andrea Giammarchi
Hi Mark, thanks for pointing that out but if I understand the problem correctly then the snippet I've suggested concatenates strings and will never produce those problematic syntax errors. Can I say it's still safe? Or do you think it might have some problem in Safari? Cheers On Sun, Mar 22,

Re: Converting strings to template strings

2015-03-22 Thread Mark S. Miller
Why on earth are you avoiding strict mode? I can't even begin to think of the hazards from handling a user-provided string to be parsed non-strict. Nor should anyone bother; sloppy mode is a mess that should simply be avoided for all new code -- especially in the careful handling of a user

Re: Supporting feature tests directly

2015-03-22 Thread Kyle Simpson
...using eval or Function is not even an option in CSP constrained environments ...that's exactly what we'd like to know, if a generic syntax will break or not. Furthermore, there are things which are valid syntax which cannot be directly `eval`'d or `Function`'d, such as `import` and

Re: ES6 module syntax – done?

2015-03-22 Thread Caridy Patino
yes, we just don't know yet, we have to think about it. there is already a good discussion happening about the loader shim we plan to provide, etc. look into the loader repo. Sent from my iPhone On Mar 21, 2015, at 6:14 PM, James Kyle m...@thejameskyle.com wrote: There was then

Re: Supporting feature tests directly

2015-03-22 Thread Getify Solutions
So why not just add a sandbox, and ... means to catch error Other than the `import` / `export` thing I mentioned, for the exact reason why `eval(..)` and `new Function(..)` are not preferred (which roughly do the same thing)… A feature test that requires the entire parse/compile/execute cycle

Re: Supporting feature tests directly

2015-03-22 Thread Jordan Harband
The only concern I'd have with a symbol approach is that there are likely to be engine variances in the future - in the case of let, knowing that the syntax is supported doesn't mean that ES6's semantics apply, it just means it won't throw a SyntaxError. If that's the sole goal - detecting

Re: Converting strings to template strings

2015-03-22 Thread Mark Miller
The pattern [\S\s]*? admits a lot. Why are you confident that it can't contain a string that, for example, closes the function with an unbalanced }, then has an evil expression which evaluates, followed by an unbalanced { so the whole thing still parses? On Sun, Mar 22, 2015 at 7:38 AM, Andrea

Re: Supporting feature tests directly

2015-03-22 Thread Kyle Simpson
likely to be engine variances in the future I hope you just mean like changes that ES7 might make to an ES6 feature. And I hope those aren't syntactic as much as semantic. :) If there was a change on syntax, I would assert that should be considered a new feature with its own new test, even if