Quasi-literals for templating?

Mark S. Miller erights at google.com
Wed Jun 15 17:41:07 PDT 2011


On Wed, Jun 15, 2011 at 5:36 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Jun 15, 2011, at 4:43 PM, Mark S. Miller wrote:
>
>
>
> On Wed, Jun 15, 2011 at 4:42 PM, Axel Rauschmayer <axel at rauschma.de>wrote:
>
>> Ah, very clever. It’d be nice to have an example of using this to compile
>> templates (like jQuery templates). Maybe not even the implementation, just a
>> quasi literal and why it works.
>>
>> var myTmpl = tmpl`Dear ${{first}} ${{last}}`; // (*)
>> alert(myTempl.render({ first: "Jane", last: "Doe" }));
>>
>> The handler (at (*)) is called like this:
>> tmpl(callSiteId73654, { first: undefined }, { last: undefined });
>>
>> BTW: won’t it be a problem (for this use case) if the variables first and
>> last don’t exist?
>>
>
> It would indeed be a problem. How much does this matter?
>
>
> In ES.next unresolved resolved references to lexical bindings are early
> errors.  {first}  is equivalent to {first: first} so the RHS reference to
> first is a lexically bound unresolved reference that would produce an early
> error before the code ever ran.
>

I understand that. I'm asking how much of a problem is it if, in order to
use the pattern in question, you had to define the variables first?



>
> Allen
>
>
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/a9f6dc81/attachment.html>


More information about the es-discuss mailing list