Heads up! Quasis are no longer called Quasi, the new name is String Templates.
On Sun, Sep 23, 2012 at 11:59 AM, Matthew Robb <[email protected]>wrote: > 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 <[email protected]>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 <[email protected]>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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> - Matthew Robb >> > > > > -- > - Matthew Robb > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
