I like String.cooked best. While I agree that method names should generally be verbs, I suggest this rule should *not* be used for template literal tag names. Rather, the tag name should generally be descriptive, naming the language being parsed or the way it is interpreted or what the value of the template literal expression will be. Most often, it should name the language being parsed. By contrast with "raw", "cooked" is the right name for this language --- the language of escaped characters within a normal string literal.
Historical note: Template literals derive from E's quasi-literals http://www.erights.org/elang/grammar/quasi-overview.html . Template literal tags are E's quasi-parsers. We usually named quasi-parsers according to the language they were quasi-parsing. This is natural for most JS uses. See https://github.com/erights/quasiParserGenerator On Thu, Dec 13, 2018 at 5:42 AM T.J. Crowder < [email protected]> wrote: > On Thu, Dec 13, 2018 at 1:03 PM kai zhu > <[email protected]> wrote: > > why not copy python's list-zip static-function > > The result isn't a string, it's an array you'd then have to join with > `.join("")`. Not that `zip` isn't a useful function *too*... (At least, > presumably it is, it shows up in libs a lot. I don't recall having had to > do it outside a tag function.) > > > i'm also against the spread-operator signature. > > Good point to raise. (FWIW: It's "rest," not "spread;" and it's not an > operator.) > > An argument in favor of using a rest parameter is it aligns with > `String.raw`. (It also makes `cook` a valid tag function, though a > pointless one to use in that way as the result is what you'd get from an > untagged template.) > > An argument against using a rest parameter (taking an array instead) is > that, to my mind anyway, the primary use case for this function is as a > tool within other general-purpose tag functions (like Isiah's `debug` and > `trust` examples). In a general-purpose tag function, since you don't know > how many substitution values you're going to get, you're likely to have > used a rest parameter, meaning you already have an array. Passing the array > directly is more efficient, surely, than spreading it and having `cook` > gather it up into a rest parameter. (That said, if engines don't already > aggressively optimize calls using spread with an array that has the default > iterator to functions using a perfectly-matching rest parameter list, > presumably they will at some point, or investigations have proved it's not > worth the trouble.) > > I'm not bothered either way. > > -- T.J. Crowder > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
