Quasi-literals for templating?

Axel Rauschmayer axel at rauschma.de
Wed Jun 15 18:04:28 PDT 2011


With a let-block it’s probably not a deal breaker, but it seems like a shame that this is necessary for such a frequent use case.

It might be worth it to ask someone who has written a templating engine.

On Jun 16, 2011, at 2:41 , Mark S. Miller wrote:

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

-- 
Dr. Axel Rauschmayer

axel at rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/a54fb0f2/attachment.html>


More information about the es-discuss mailing list