What have you been calling the MemberExpression TemplateLiteral and
CallExpression TemplateLiteral forms?
Those are two variations of the Tagged String Literals form.
___
es-discuss mailing list
es-discuss@mozilla.org
What have you been calling the MemberExpression TemplateLiteral and
CallExpression
TemplateLiteral forms?
On Wed, Mar 25, 2015 at 10:59 PM, Kyle Simpson get...@gmail.com wrote:
I've dubbed them Interpolated String Literals (or Interpolated
Strings) in my writings and materials going forward. I
In general, if you want to have control over those arguments, reusing the
template without the need of the wrapping function, you will have to provide a
way to apply logic inside the template string, that complicates things a lot.
As for i18n, ICU messages can solve that part of the puzzle
Even a function wouldn't scale that well for i18n purpose, 'cause you
should write either a function per language or each language switch
statement per function.
I see current ES6 string templates good for debug purpose only, and not
much else ... maybe English centric developers tools so few,
Mark, is really deadly simple 5 lines of code script which aim is to access
properties without having conflicts with names (using `with(this)`) without
needing SES or anything else in, without needing to change, it's simplified
string templating that works with dynamic strings.
Why do we need
But from the few data points I have, approximately 100% of web
developers, when they first hear template strings are in ES6, think
that means something like Mustache in the standard library. Some
initially try to use the feature that way and get frustrated. I expect
widespread confusion on
On Sun, Mar 22, 2015 at 10:27 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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
Jason Orendorff wrote:
But from the few data points I have, approximately 100% of web
developers, when they first hear template strings are in ES6, think
that means something like Mustache in the standard library. Some
initially try to use the feature that way and get frustrated. I expect
Is it too late to go back to quasi-literals?
(Joking!)
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Jason
Orendorff
Sent: Monday, March 23, 2015 18:52
To: Mark S. Miller
Cc: Mark Miller; es-discuss@mozilla.org
Subject: Re: Converting strings
On Mon, Mar 23, 2015 at 1:55 AM, Mark S. Miller erig...@google.com wrote:
String templates are not good for templates, these work only for
statically defined code and in place meaning you cannot grab content from a
DB and inject values like names or numbers as you would do with any
templating
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
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
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 +
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
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,
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
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
17 matches
Mail list logo
