Quasi-literals for templating?

Mike Samuel mikesamuel at gmail.com
Mon Jun 13 23:11:42 PDT 2011


2011/6/13 Gavin Barraclough <barraclough at apple.com>:
> On Jun 12, 2011, at 4:35 AM, Axel Rauschmayer wrote:
>
> BTW: “Desugaring” at the beginning of “Semantics” seems mangled.
>
> I was just about to hit send an email saying the same thing!
> Also, the section on the default quasi tag the name expandedLP is used,
> where I think this should be unescapedLP?
> On this topic, rawLP and unescapedLP seem to be poor names.  'LP' seems to
> be meaningless line noise to developers using the feature who are not
> familiar with the grammar in the spec (and should not need to be).  Maybe
> these could just raw & unescaped? - or rawLiterals/rawLiteralPortion/etc for
> something more verbose?

The names there are my fault.  The last meeting decided what to
include there, but we never got into names, and I chose bad ones.

> > Has that been considered as a use case (e.g. after a compilation/generation
> > step?). But it doesn’t seem like identifier names are accessible to quasi
> > handlers, which would make this difficult.
>
> This too!  Given the example for the proposal:
> msg`Welcome to ${siteName}, you are visitor number ${visitorNumber}!`
> It would seem useful if the same quasi could handle both of these formatting
> tasks:
> msg`Welcome to ${siteName}, you are visitor number ${visitorNumber}!`
> msg`Welcome, you are visitor number ${visitorNumber} to ${siteName}!`
> And it seems the identifiers could help.  Presumably the identifier names
> could be stored in a new frozen array on the call site specific object?

This is quite possible.  What exactly is stored might become confusing
if the committee's consensus is that SubstitutionBody should allow
more than just dotted identifiers.

>  Might it also be useful to provide a mechanism to override the identifier
> with something clearer, for example, if the visitor number were being read
> from the property 'obj().x',
> msg`Welcome to ${siteName}, you are visitor number ${visitorNumber:
> obj().x}!`

I think overloading colon would be a bad idea, and I think the best
syntax for expressing property visitorNumber of obj().x is
obj().x.visitorNumber.

Allowing overriding is problematic if it means that identifiers in the
local scope other than those mentioned in the substitution body can be
read.

> Also, what is the 'this' object passed to the quasi handler? - might it make
> sense for 'this' to be the site specific object, rather than the passing
> this as an argument?

If the quasi handler is a member expression as in foo.bar`baz${boo}`
then "this" is the left operand of the member expression, foo in that
example.

> this seems to make some logical sense, and makes the

Making the call-site object only available via `this` would prevent
bound methods from using it.


> arguments passed to function simpler to comprehend - they are all the
> substitution values, and arguments.length now matches the number of
> substitutions, indexed from zero, rather than being arguments length - 1.
>  E.g. the first example in the proposal:
>
> // hoisted declaration.
> const callSiteId1234 = {
>     rawLP: ['quasiLiteralPart1 ', ' quasiLiteralPart2'],
>     unescapedLP: ['quasiLiteralPart1 ', ' quasiLiteralPart2']
> };
>
> // in-situ
> quasiHandlerName(callSiteId1234, quasiSubstitution)
>
> would instead call:
>
> // in-situ
> quasiHandlerName.call(callSiteId1234, quasiSubstitution)
>
> cheers,
> G.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list