| 00:58 | <jschoi> | Should it be called an operator? It’s not like it evaluates into an expression by itself—it’s kind of more like spread syntax, right? “Interpolation syntax”, maybe… |
| 00:59 | <jschoi> | I’m just thinking about that sentence on the MDN chart of operators that says, “The spread operator is not in this list because it is not an operator,” and wondering if inconsistently saying “interpolation operator” might confuse learners. |
| 01:00 | <jschoi> | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence#table |
| 01:01 | <jschoi> | Interpolation whatever-we-call-it wouldn’t belong on this operator chart, either. |
| 01:02 | <jschoi> | (I do like and appreciate the word “interpolation” much more than “pin”, for what it’s worth.) |
| 01:03 | <joepie91 🏳️🌈> | "the spread operator is not an operator" seems like a dubious statement |
| 01:03 | <joepie91 🏳️🌈> | like, it may be true according to some strict technical definition, but I'm not sure it's true by anyone's pragmatic definition |
| 01:04 | <ljharb> | spread is definitely not an operator, because it doesn’t work anywhere in expression position |
| 01:04 | <ljharb> | similarly yes, I’d call the ${} “placeholder syntax” (cc TabAtkins) |
| 01:05 | <ljharb> | or “interpolation placeholder syntax”, i suppose, to disambiguate from pipeline |
| 01:05 | <jschoi> | (I like “interpolation syntax” more than “placeholder syntax”, for what it’s worth. “Placeholder syntax” makes me think of the pipe operator and PFA syntax, haha.) |
| 01:05 | <jschoi> | Yes. |
| 01:08 | <ljharb> | i also prefer the name “interpoliterals” over template literals too, as long as we’re naming things :-p |
| 01:12 | <TabAtkins> | I don't think operators have to be usable in any context to be reasonably called that? My definition is relatively broad. |
| 01:12 | <TabAtkins> | Spread is def an operator, to me. ${} is as much as operator as () is |
| 01:12 | <joepie91 🏳️🌈> | yeah, that's pretty much what I was alluding to with "pragmatic definition" |
| 01:13 | <joepie91 🏳️🌈> | as far as people's mental models are concerned, how they reason about how the language works, it certainly seems to be an operator |
| 01:13 | <TabAtkins> | Yeah I agree with you |
| 01:13 | <joepie91 🏳️🌈> | even if it may not meet certain strict technical definitions of one, and may not be one implementation-wise |
| 01:16 | <bakkot> | that definitely does not match my mental model of how languages work |
| 01:16 | <bakkot> | operators are things which turn values into other values |
| 01:17 | <bakkot> | neither spread nor ${} is an operator in that sense |
| 01:19 | <jschoi> | I don't think operators have to be usable in any context to be reasonably called that? My definition is relatively broad. |
| 01:28 | <joepie91 🏳️🌈> | strictly following technical correctness rather than leaving room for simplifications frequently results in worse explainers, though, from a didactic point of view |
| 01:29 | <joepie91 🏳️🌈> | technical accuracy certainly is an important factor to weigh, but not the only one |
| 01:29 | <joepie91 🏳️🌈> | (a lot of the complaints about MDN being 'difficult to understand' seem to relate to this) |
| 02:07 | <jschoi> | strictly following technical correctness rather than leaving room for simplifications frequently results in worse explainers, though, from a didactic point of view |
| 02:09 | <jschoi> | For what it’s worth, I do personally find value in distinguishing “things that combine expressions into expressions” (operators) from “things that don’t result in expressions” (not operators)—and I suspect that this distinction may have teaching value to learners too—but that’s my own intuition, and I am only one being of many, haha. |
| 10:32 | <joepie91 🏳️🌈> | I do agree that it's valuable to teach that distinction actually (I also tend to put a lot of focus on expression vs. statement in what I teach, for example), I'm just not sure that an operator reference is the right place :D |
| 22:07 | <TabAtkins> | Question ended up being moot, fwiw; I went with "interpolation pattern" instead. |