3 ms·
Tagged template literals in JS have all that complexity. All of it. That tools you trust lie and pretend that's not the case doesn't make the language spec say
by conartist6 2y ago
Tagged template literals in JS have all that complexity. All of it. That tools you trust lie and pretend that's not the case doesn't make the language spec say anything different
- Timon3 2y agoNo, they literally don't, because they don't support these features! You can't split apart the declaration of the template literal and the "tagging". The tag is always part of the declaration, which it doesn't have to be in Python, as I've showed. You can't pass additional parameters to the tag function, it's always just the template & values. In Python, you can pass as many parameters as you want to the usage site, e.g. some_value = html(True, t"<something />", 42)
- conartist6 2y agoIt just sounds like you don't know JS very well, because in JS you can definitely split apart the declaration and the tag with ease. The thing implementing the tag is just a function after all: https://jsfiddle.net/rd2f1kot/ https://jsfiddle.net/rd2f1kot/
- Timon3 2y agoSorry, but do just not want to understand what I'm talking about? Your example doesn't show what you're saying it does. In Python you can do this: bar = "hello world" template = t"<something foo={bar} />" string = html(template) This is simply not possible in JS, because the template literal always must have the tag attached. You can't split them apart. If you try: const bar = "hello world" const template = `<something foo=${bar} />` you already have a string in the `template` variable. There's no access to the individual values anymore. It's already done. It's a string. No template. You can't pull apart the literal declaration and the tagging. Are we now done with this ridiculous game of deliberate misunderstandings?
- conartist6 2y agoI just don't see the same thing as you. This is what you say is simply not possible: let passthrough = (...args) => args; let bar = "hello world"; let template = passthrough`<something foo=${bar} />`; string = html(...template);
- Timon3 2y agoSo now we have moved from "tagged template literals have all the complexity of Python templates" to "if you define a specific template tag and use that, you can replicate one feature of Python templates". No mention of the other example I mentioned (which, by the way, wasn't an exhaustive list). Now, I'll just ignore that you're still deliberately misrepresenting me in the hopes of gaining some actual knowledge from this discussion - please show me: which editor supports syntax highlighting for the specific example you just mentioned? After all, that was the topic of discussion - not whether it's possible to delay "tagging", but whether it's easier to do syntax highlighting for JS template tags. Please show me an existing editor, IDE or git repo for a tool that would highlight your specific example based on the `html(...template)` call in line 4 (so no heuristics based on line 3). Surely you're not just throwing random examples at the wall to see what sticks, right? You've actually been following the discussion and are arguing in the context of it?
- conartist6 2y agoOh now I can reply. Thread continued above: https://news.ycombinator.com/item?id=43754585 https://news.ycombinator.com/item?id=43754585
- conartist6 2y agoSorry for some reason I can't reply to the deeper posts. Depth limit I guess. You asked which editors could support syntax highlighting once the tag and the content that needs to be syntax highlighted are split apart. Currently there are none, though I am writing one that will be able to. Python should be able to detect the magic syntactic pattern just the same way JS does and use that for syntax higlighting. In JS the magic syntactic pattern for triggering HTML syntax highlighting is: html`<doc/>` In Python the magic syntactic pattern would be: html(t"<doc />") My point in showing that JS counterexample was to demonstrate that the real reason people don't do that kind of thing isn't that they can't, it's that they like having syntax highlighting. That means the approach should work just as well in Python. This is the case even though the heuristic involved is very weak. Changing the name of the identifier or breaking into multiple expressions would be enough to break the heuristic in either language, which is why I think it's a really weak heuristic and dangerous pitfall for developers who might mistake the coloring for information about how the runtime sees that data (which is normally what syntax highlighting is for)