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 <[email protected]> > wrote: > > On Jun 15, 2011, at 4:43 PM, Mark S. Miller wrote: > >> >> >> On Wed, Jun 15, 2011 at 4:42 PM, Axel Rauschmayer <[email protected]> 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 [email protected] twitter.com/rauschma home: rauschma.de blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
