Quasi literal function call syntax

Matthew Robb matthewwrobb at gmail.com
Sun Sep 23 08:59:31 PDT 2012


BUT, just putting this out there, I do think it would be great to have a
Quasi global constructor that could have some static members hanging off of
it, possibly including a potential parse method, but also some of the more
likely bundled output:

Quasi.escape`my ${unsafe} stuff`

On Sun, Sep 23, 2012 at 11:56 AM, Matthew Robb <matthewwrobb at gmail.com>wrote:

> 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
>



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


More information about the es-discuss mailing list