Quasi literal function call syntax

[Matthew Robb]

I had the same initial reaction, however, working with desugaring both
quasi-literals and their tagged brothers has brought me to a new
appreciation for their elegance. Actually using the tagged quasis has a
powerful feel to it and it can help expose people to what's actually
happening under the hood. It's not a simple shorthand for concatenation and
without seeing that most people will miss the potential I think.

On Sun, Sep 23, 2012 at 11:53 AM, Aron Homberg <info at aron-homberg.de> wrote:

> Hi all,
>
> currently I'm reading the recent draft spec of edition 6 from 7-8-12 and I
> was a bit suprised about the special function call syntax in relation to
> quasi literals e.g.:
>
>     safehtml`Some tpl text ${variableToPlaceHere} more text.`
>
> which will result in a call like:
>
> function safehtml(/*Array*/ tplParts, ...tplValues) {
>     // ...
> }
>
> correct?
>
> I think this special function call syntax has a relative high
> "wtf?!"-factor ;-) (like <| had :)
>
> Because this special use case mostly targets to library developers (I
> guess, because the most app developers will just use var tpl = `abc ${var1}
> ...` etc.)
> I think a more straight forward approach without a special grammar would
> be nice.
>
> I just wanted to know what you think about the following approach using a
> new built-in function, which acts like parseFloat() or parseInt() - just
> for quasi literals:
>
>     var parsedQuasi = parseQuasi('Some tpl text ${variableToPlaceHere}
> more text.');
>
> The result variable would contain e.g. an array or an object (plain or of
> prototype Quasi with methods like getParts(), getValues()) which contains
> the parts and the assigned values.
>
> Simply it would be:
>
>     safehtml(parseQuasi('Some tpl text ${variableToPlaceHere} more
> text.'));
>
> Instead of:
>
>     safehtml`Some tpl text ${variableToPlaceHere} more text.`
>
> This would:
> - (pro) reduce the complexity of the parsing grammar
> - (pro) result in a more straight forward function call syntax without
> special cases (magic)
> - (pro) follow the built-in functions "standard" for preprocessing special
> values (parseNumber(), parseInt() functions)
> - (con) but it also would break the `` syntax - because in case of
> parseQuasi()-calling the ' or " would be used
>
> What do you think?
>
> Thanks and regards,
> Aron
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Matthew Robb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120923/db178ceb/attachment-0001.html>