Re: A Function.tag proposal?
By the way, the VS Code plugin I use is [Comment tagged templates](https://marketplace.visualstudio.com/items?itemName=bierner.comment-tagged-templates). Works great, allows any extension in the comment, and it will highlight as long as you have that syntax installed separately. I got tired of pasting my identity tag everywhere. #!/JoePea On Thu, Sep 24, 2020 at 2:25 PM #!/JoePea wrote: > > I mean, it would be only a parse time cost if the identity tag is used like > > ```js > String.tag`...anything...` > ``` > > assuming it is not monkey-patchable (readonly). But maybe if it is > patchable then all bets are off, and it has a runtime cost. > > #!/JoePea > > On Thu, Sep 24, 2020 at 2:22 PM #!/JoePea wrote: > > > > Perhaps a built-in identity tag would be only a parse-time performance cost. > > #!/JoePea > > > > On Thu, Sep 24, 2020 at 2:21 PM #!/JoePea wrote: > > > > > > I don't know what you mean about the raw stuff, but using `/*css*/` > > > works perfectly fine in VS Code with a plugin. There's no reason > > > intellisense can't work inside the commented string. If you meant > > > about completing the `css` part, if you accidentally write `/*ccs*/` > > > then the colors won't look right. Missing auto-completion inside the > > > little comment isn't that bad. > > > > > > I prefer using the comment because using an identity tag just for > > > syntax feels like I'm adding a performance cost for no reason related > > > to my runtime code. > > > > > > But perhaps a built-in identity tag would be fast. > > > > > > #!/JoePea > > > > > > On Mon, Jun 22, 2020 at 11:02 AM Andrea Giammarchi > > > wrote: > > > > > > > > I think it doesn't matter where it lands, and I've overlooked at the > > > > already available String.raw. > > > > > > > > My idea is to have it "no matter where, or how named" as it's the > > > > functionality I am after, not the name. > > > > > > > > String.plain sounds great, but since template literals tag functions > > > > are named "template literals tag functions", I've thought String.tag > > > > would implicitly describe the intent. > > > > > > > > And then again, I don't care about the name, "we" (developers that use > > > > template literals a lot) would love it no matter how it's called ;-) > > > > > > > > On Mon, Jun 22, 2020 at 7:16 PM Bergi wrote: > > > >> > > > >> Hi Andrea, > > > >> > > > >> my 5ct: Putting the static function on the `Function` object doesn't > > > >> make any sense to me. Using `String.tag` seems like much more sensible > > > >> choice. Or, how about `String.plain`, in contrast to `String.raw`? > > > >> > > > >> I can see the use case, altough I'd really prefer tooling to become > > > >> more > > > >> intelligent in that regard. > > > >> > > > >> best, > > > >> Bergi > > > >> ___ > > > >> es-discuss mailing list > > > >> [email protected] > > > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > ___ > > > > es-discuss mailing list > > > > [email protected] > > > > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
I mean, it would be only a parse time cost if the identity tag is used like ```js String.tag`...anything...` ``` assuming it is not monkey-patchable (readonly). But maybe if it is patchable then all bets are off, and it has a runtime cost. #!/JoePea On Thu, Sep 24, 2020 at 2:22 PM #!/JoePea wrote: > > Perhaps a built-in identity tag would be only a parse-time performance cost. > #!/JoePea > > On Thu, Sep 24, 2020 at 2:21 PM #!/JoePea wrote: > > > > I don't know what you mean about the raw stuff, but using `/*css*/` > > works perfectly fine in VS Code with a plugin. There's no reason > > intellisense can't work inside the commented string. If you meant > > about completing the `css` part, if you accidentally write `/*ccs*/` > > then the colors won't look right. Missing auto-completion inside the > > little comment isn't that bad. > > > > I prefer using the comment because using an identity tag just for > > syntax feels like I'm adding a performance cost for no reason related > > to my runtime code. > > > > But perhaps a built-in identity tag would be fast. > > > > #!/JoePea > > > > On Mon, Jun 22, 2020 at 11:02 AM Andrea Giammarchi > > wrote: > > > > > > I think it doesn't matter where it lands, and I've overlooked at the > > > already available String.raw. > > > > > > My idea is to have it "no matter where, or how named" as it's the > > > functionality I am after, not the name. > > > > > > String.plain sounds great, but since template literals tag functions are > > > named "template literals tag functions", I've thought String.tag would > > > implicitly describe the intent. > > > > > > And then again, I don't care about the name, "we" (developers that use > > > template literals a lot) would love it no matter how it's called ;-) > > > > > > On Mon, Jun 22, 2020 at 7:16 PM Bergi wrote: > > >> > > >> Hi Andrea, > > >> > > >> my 5ct: Putting the static function on the `Function` object doesn't > > >> make any sense to me. Using `String.tag` seems like much more sensible > > >> choice. Or, how about `String.plain`, in contrast to `String.raw`? > > >> > > >> I can see the use case, altough I'd really prefer tooling to become more > > >> intelligent in that regard. > > >> > > >> best, > > >> Bergi > > >> ___ > > >> es-discuss mailing list > > >> [email protected] > > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > > ___ > > > es-discuss mailing list > > > [email protected] > > > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
Perhaps a built-in identity tag would be only a parse-time performance cost. #!/JoePea On Thu, Sep 24, 2020 at 2:21 PM #!/JoePea wrote: > > I don't know what you mean about the raw stuff, but using `/*css*/` > works perfectly fine in VS Code with a plugin. There's no reason > intellisense can't work inside the commented string. If you meant > about completing the `css` part, if you accidentally write `/*ccs*/` > then the colors won't look right. Missing auto-completion inside the > little comment isn't that bad. > > I prefer using the comment because using an identity tag just for > syntax feels like I'm adding a performance cost for no reason related > to my runtime code. > > But perhaps a built-in identity tag would be fast. > > #!/JoePea > > On Mon, Jun 22, 2020 at 11:02 AM Andrea Giammarchi > wrote: > > > > I think it doesn't matter where it lands, and I've overlooked at the > > already available String.raw. > > > > My idea is to have it "no matter where, or how named" as it's the > > functionality I am after, not the name. > > > > String.plain sounds great, but since template literals tag functions are > > named "template literals tag functions", I've thought String.tag would > > implicitly describe the intent. > > > > And then again, I don't care about the name, "we" (developers that use > > template literals a lot) would love it no matter how it's called ;-) > > > > On Mon, Jun 22, 2020 at 7:16 PM Bergi wrote: > >> > >> Hi Andrea, > >> > >> my 5ct: Putting the static function on the `Function` object doesn't > >> make any sense to me. Using `String.tag` seems like much more sensible > >> choice. Or, how about `String.plain`, in contrast to `String.raw`? > >> > >> I can see the use case, altough I'd really prefer tooling to become more > >> intelligent in that regard. > >> > >> best, > >> Bergi > >> ___ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > > > > ___ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
I don't know what you mean about the raw stuff, but using `/*css*/` works perfectly fine in VS Code with a plugin. There's no reason intellisense can't work inside the commented string. If you meant about completing the `css` part, if you accidentally write `/*ccs*/` then the colors won't look right. Missing auto-completion inside the little comment isn't that bad. I prefer using the comment because using an identity tag just for syntax feels like I'm adding a performance cost for no reason related to my runtime code. But perhaps a built-in identity tag would be fast. #!/JoePea On Mon, Jun 22, 2020 at 11:02 AM Andrea Giammarchi wrote: > > I think it doesn't matter where it lands, and I've overlooked at the already > available String.raw. > > My idea is to have it "no matter where, or how named" as it's the > functionality I am after, not the name. > > String.plain sounds great, but since template literals tag functions are > named "template literals tag functions", I've thought String.tag would > implicitly describe the intent. > > And then again, I don't care about the name, "we" (developers that use > template literals a lot) would love it no matter how it's called ;-) > > On Mon, Jun 22, 2020 at 7:16 PM Bergi wrote: >> >> Hi Andrea, >> >> my 5ct: Putting the static function on the `Function` object doesn't >> make any sense to me. Using `String.tag` seems like much more sensible >> choice. Or, how about `String.plain`, in contrast to `String.raw`? >> >> I can see the use case, altough I'd really prefer tooling to become more >> intelligent in that regard. >> >> best, >> Bergi >> ___ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > ___ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
I think it doesn't matter where it lands, and I've overlooked at the already available String.raw. My idea is to have it "no matter where, or how named" as it's the functionality I am after, not the name. String.plain sounds great, but since template literals tag functions are named "template literals tag functions", I've thought String.tag would implicitly describe the intent. And then again, I don't care about the name, "we" (developers that use template literals a lot) would love it no matter how it's called ;-) On Mon, Jun 22, 2020 at 7:16 PM Bergi wrote: > Hi Andrea, > > my 5ct: Putting the static function on the `Function` object doesn't > make any sense to me. Using `String.tag` seems like much more sensible > choice. Or, how about `String.plain`, in contrast to `String.raw`? > > I can see the use case, altough I'd really prefer tooling to become more > intelligent in that regard. > > best, > Bergi > ___ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
Hi Andrea, my 5ct: Putting the static function on the `Function` object doesn't make any sense to me. Using `String.tag` seems like much more sensible choice. Or, how about `String.plain`, in contrast to `String.raw`? I can see the use case, altough I'd really prefer tooling to become more intelligent in that regard. best, Bergi ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
btw, in case somebody reads this issue, this is the current workaround:
```js
const tag = (raw, ...values) => String.raw({raw}, ...values);
```
it's still better than my dummy tag (hopefully at least on performance),
but as it's becoming more common than ever, it'd be great to have
`String.tag` doing exactly that.
Best Regards
On Mon, Jun 22, 2020 at 2:30 PM Andrea Giammarchi <
[email protected]> wrote:
> It doesn't work. There's been a lengthy discussion here
> https://github.com/mjbvz/vscode-lit-html/issues/14 and comments are not
> welcome in most tools, but even GitHub fails at highlighting the string,
> and no intellisense works within comments.
>
> The simplest request considered as "increased JS complexity" also feels a
> bit of an exaggeration: there are various use cases, and I wouldn't have
> proposed this if useless.
>
> Although, `String.tag` instead of `String.raw` seems like a welcome
> compromise, actually even more semantic, so the proposal would be to add a
> tag that does exactly what `String.raw` does without escaping sequences.
>
> As there is already an identical function that is a footgun for the
> described use-case, I don't see any extra complexity in having `String.tag`.
>
> Best Regards.
>
> On Mon, Jun 22, 2020 at 2:00 PM Bruno Macabeus
> wrote:
>
>> You could just use comments in order to provide metainformations to your
>> developer tools instead of adding a new feature on language.
>>
>> const style = /*css*/`
>> body {
>> color: green;
>> }
>> `;
>>
>> const node = /*html*/`
>> hello world
>> `;
>>
>> Or an even better solution is change your highlight to firstly try to match
>> a HTML, if fail try to match CSS, if fail match as a plain string.
>>
>> IMHO it isn't necessary to increase the complexity of JS to do that.
>>
>>
>> On Mon, 22 Jun 2020 at 12:02, François REMY <
>> [email protected]> wrote:
>>
>>> What exactly are you proposing to do differently than String.raw?
>>>
>>>
>>> https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
>>>
>>> Sent from my phone
>>> --
>>> *From:* es-discuss on behalf of Andrea
>>> Giammarchi
>>> *Sent:* Monday, June 22, 2020 12:24:13 PM
>>> *To:* [email protected]
>>> *Subject:* A Function.tag proposal?
>>>
>>> This is something somehow bothering developers and tools, sooner or
>>> later, the need for a no-op template literal tag function that just returns
>>> the string as is.
>>>
>>> The current workaround to have highlights, proper content minification,
>>> etc, is the following one:
>>>
>>> ```js
>>>
>>> import css from 'dummy-tag';import html from 'dummy-tag';
>>> const style = css` body {color: green; }`;
>>> const node = html` hello world`;
>>>
>>> ```
>>>
>>> but as irrelevant as the dummy-tag code is, in size, it's a dependency,
>>> and a function that can't get easily optimized, due the nature of the tag
>>> signature.
>>>
>>> ### Proposal
>>>
>>> Provide a static `Function.tag` which internally flattens out any
>>> template literal content.
>>>
>>> ```js
>>>
>>> const css = Function.tag;
>>> const html = Function.tag;
>>>
>>> const style = css` body {color: green; }`;
>>> const node = html` hello world`;
>>>
>>> ```
>>>
>>> Internally it will place eventual interpolations within template chunks,
>>> and return a string.
>>>
>>> ```js
>>> Function.tag`1${2}3` === '123';
>>> ```
>>>
>>> That's it. Thoughts?
>>>
>>> Best Regards
>>>
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
It doesn't work. There's been a lengthy discussion here
https://github.com/mjbvz/vscode-lit-html/issues/14 and comments are not
welcome in most tools, but even GitHub fails at highlighting the string,
and no intellisense works within comments.
The simplest request considered as "increased JS complexity" also feels a
bit of an exaggeration: there are various use cases, and I wouldn't have
proposed this if useless.
Although, `String.tag` instead of `String.raw` seems like a welcome
compromise, actually even more semantic, so the proposal would be to add a
tag that does exactly what `String.raw` does without escaping sequences.
As there is already an identical function that is a footgun for the
described use-case, I don't see any extra complexity in having `String.tag`.
Best Regards.
On Mon, Jun 22, 2020 at 2:00 PM Bruno Macabeus
wrote:
> You could just use comments in order to provide metainformations to your
> developer tools instead of adding a new feature on language.
>
> const style = /*css*/`
> body {
> color: green;
> }
> `;
>
> const node = /*html*/`
> hello world
> `;
>
> Or an even better solution is change your highlight to firstly try to match a
> HTML, if fail try to match CSS, if fail match as a plain string.
>
> IMHO it isn't necessary to increase the complexity of JS to do that.
>
>
> On Mon, 22 Jun 2020 at 12:02, François REMY
> wrote:
>
>> What exactly are you proposing to do differently than String.raw?
>>
>>
>> https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
>>
>> Sent from my phone
>> --
>> *From:* es-discuss on behalf of Andrea
>> Giammarchi
>> *Sent:* Monday, June 22, 2020 12:24:13 PM
>> *To:* [email protected]
>> *Subject:* A Function.tag proposal?
>>
>> This is something somehow bothering developers and tools, sooner or
>> later, the need for a no-op template literal tag function that just returns
>> the string as is.
>>
>> The current workaround to have highlights, proper content minification,
>> etc, is the following one:
>>
>> ```js
>>
>> import css from 'dummy-tag';import html from 'dummy-tag';
>> const style = css` body {color: green; }`;
>> const node = html` hello world`;
>>
>> ```
>>
>> but as irrelevant as the dummy-tag code is, in size, it's a dependency,
>> and a function that can't get easily optimized, due the nature of the tag
>> signature.
>>
>> ### Proposal
>>
>> Provide a static `Function.tag` which internally flattens out any
>> template literal content.
>>
>> ```js
>>
>> const css = Function.tag;
>> const html = Function.tag;
>>
>> const style = css` body {color: green; }`;
>> const node = html` hello world`;
>>
>> ```
>>
>> Internally it will place eventual interpolations within template chunks,
>> and return a string.
>>
>> ```js
>> Function.tag`1${2}3` === '123';
>> ```
>>
>> That's it. Thoughts?
>>
>> Best Regards
>>
>>
>>
>> ___
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
That is not raw. On Mon, Jun 22, 2020 at 1:02 PM François REMY wrote: > What exactly are you proposing to do differently than String.raw? > > > https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw > > Sent from my phone > -- > *From:* es-discuss on behalf of Andrea > Giammarchi > *Sent:* Monday, June 22, 2020 12:24:13 PM > *To:* [email protected] > *Subject:* A Function.tag proposal? > > This is something somehow bothering developers and tools, sooner or later, > the need for a no-op template literal tag function that just returns the > string as is. > > The current workaround to have highlights, proper content minification, > etc, is the following one: > > ```js > > import css from 'dummy-tag';import html from 'dummy-tag'; > const style = css` body {color: green; }`; > const node = html` hello world`; > > ``` > > but as irrelevant as the dummy-tag code is, in size, it's a dependency, > and a function that can't get easily optimized, due the nature of the tag > signature. > > ### Proposal > > Provide a static `Function.tag` which internally flattens out any template > literal content. > > ```js > > const css = Function.tag; > const html = Function.tag; > > const style = css` body {color: green; }`; > const node = html` hello world`; > > ``` > > Internally it will place eventual interpolations within template chunks, > and return a string. > > ```js > Function.tag`1${2}3` === '123'; > ``` > > That's it. Thoughts? > > Best Regards > > > > ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
You could just use comments in order to provide metainformations to your
developer tools instead of adding a new feature on language.
const style = /*css*/`
body {
color: green;
}
`;
const node = /*html*/`
hello world
`;
Or an even better solution is change your highlight to firstly try to
match a HTML, if fail try to match CSS, if fail match as a plain
string.
IMHO it isn't necessary to increase the complexity of JS to do that.
On Mon, 22 Jun 2020 at 12:02, François REMY
wrote:
> What exactly are you proposing to do differently than String.raw?
>
>
> https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
>
> Sent from my phone
> --
> *From:* es-discuss on behalf of Andrea
> Giammarchi
> *Sent:* Monday, June 22, 2020 12:24:13 PM
> *To:* [email protected]
> *Subject:* A Function.tag proposal?
>
> This is something somehow bothering developers and tools, sooner or later,
> the need for a no-op template literal tag function that just returns the
> string as is.
>
> The current workaround to have highlights, proper content minification,
> etc, is the following one:
>
> ```js
>
> import css from 'dummy-tag';import html from 'dummy-tag';
> const style = css` body {color: green; }`;
> const node = html` hello world`;
>
> ```
>
> but as irrelevant as the dummy-tag code is, in size, it's a dependency,
> and a function that can't get easily optimized, due the nature of the tag
> signature.
>
> ### Proposal
>
> Provide a static `Function.tag` which internally flattens out any template
> literal content.
>
> ```js
>
> const css = Function.tag;
> const html = Function.tag;
>
> const style = css` body {color: green; }`;
> const node = html` hello world`;
>
> ```
>
> Internally it will place eventual interpolations within template chunks,
> and return a string.
>
> ```js
> Function.tag`1${2}3` === '123';
> ```
>
> That's it. Thoughts?
>
> Best Regards
>
>
>
> ___
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Re: A Function.tag proposal?
What exactly are you proposing to do differently than String.raw? https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw Sent from my phone From: es-discuss on behalf of Andrea Giammarchi Sent: Monday, June 22, 2020 12:24:13 PM To: [email protected] Subject: A Function.tag proposal? This is something somehow bothering developers and tools, sooner or later, the need for a no-op template literal tag function that just returns the string as is. The current workaround to have highlights, proper content minification, etc, is the following one: ```js import css from 'dummy-tag'; import html from 'dummy-tag'; const style = css` body { color: green; } `; const node = html` hello world `; ``` but as irrelevant as the dummy-tag code is, in size, it's a dependency, and a function that can't get easily optimized, due the nature of the tag signature. ### Proposal Provide a static `Function.tag` which internally flattens out any template literal content. ```js const css = Function.tag; const html = Function.tag; const style = css` body { color: green; } `; const node = html` hello world `; ``` Internally it will place eventual interpolations within template chunks, and return a string. ```js Function.tag`1${2}3` === '123'; ``` That's it. Thoughts? Best Regards ___ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
