| 16:31 | <Kris Kowal> | I do not have a strong opinion. My weak opinion teeters. Just facts: TextEncoder had to be static because the byte array could not be the receiver. The “into” term indicates that writer array is an argument, not a return or the receiver. By contrast “copyWithin” implies both the reader and writer are the receiver. I don’t know a modifier word precedent for indicating the operation writes to the receiver and reads from an argument. |
| 16:35 | <Kris Kowal> | So nothing prevents the method from being on the prototype but it is easier to name on the constructor. |
| 17:05 | <rbuckton> | write? |
| 17:06 | <Richard Gibson> |
Plausibly |
| 17:07 | <TabAtkins> | fill sounds very reasonable, imo |
| 17:07 | <rbuckton> | Maybe set? DataView.prototype.setUint32() sets multiple bytes on the receiver from an argument. |
| 17:08 | <rbuckton> | fill usually means performing a repetitive action, like "fill this array with zeroes" |
| 17:09 | <Richard Gibson> | yep, set appears to be the other prior instance of that pattern |
| 17:10 | <rbuckton> | This is also a somewhat new capability in the standard library, so something precedent-setting isn't necessarily uncalled for. I would generally use a term like write for this kind of operation elsewhere. |
| 17:11 | <rbuckton> | Also, decode has some precedent with decodeURI/decodeURIComponent, so decodeBase64Into is a possibility. |
| 17:12 | <Richard Gibson> | I think the overarching point is that we ought to avoid "into" in the naming of a prototype method that writes into its receiver |
| 17:13 | <rbuckton> | The name I would normally use for such a method, were it on the prototype, would be writeBase64Bytes() |
| 17:15 | <rbuckton> | set doesn't seem like the right precedent, because its essentially a byte-for-byte copy. There's no encoding that happens (aside from byte order) |
| 17:15 | <Richard Gibson> | setFromBase64 and writeFromBase64 seem like solid options. writeBase64Bytes isn't as strong IMO, but also isn't bad. |
| 17:16 | <rbuckton> | The term byte has precedent within the language, despite referring to it as Uint8 on DataView and in the TypedArray constructor. BYTES_PER_ELEMENT, byteLength, etc. |
| 17:19 | <rbuckton> | Also, writeBase64Bytes means it could theoretically be applied to any typedarray prototype with the same meaning (i.e., "write the bytes"). An Int32Array.prototype.writeFromBase64, for example, might be misconstrued as decoding base64 into Int32 elements, rather that bytes. writeFromBase64 is probably fine if its only on Uint8Array (or maybe Int8Array). |
| 17:42 | <Kris Kowal> | I think writeBase64 is sufficiently specific and would be equally sensible on DataView or Uint8Array (and variants). |
| 17:43 | <bakkot> | plan is for these to only be on Uint8Array specifically, so I'm not too worried about the interpretation on other TA types |
| 17:43 | <bakkot> | I would find base64-decoding to non-byte types confusing |
| 17:45 | <Kris Kowal> | I don’t like it but set has much stronger precedent than write |
| 17:45 | <bakkot> | re: set vs write, we have a bunch of methods called "set" and none called "write", and the names themselves don't seem to suggest that one of them does decoding, so I'm inclined more towards set |
| 17:46 | <bakkot> | the DataView setUint32 etc methods are arguably doing encoding, especially given the endianness parameter |
| 17:46 | <bakkot> | so of the names above, setFromBase64 is my preference |
| 17:47 | <bakkot> | not opposed to write, but set seems nicer |
| 17:47 | <bakkot> | and it sounds like people are leaning towards having this on the prototype rather than a static? |
| 17:53 | <bakkot> | ok maybe no one actually cares about prototype vs static? |
| 18:25 | <rbuckton> | As I said, my biggest concern for set is that methods like setInt32 imply a byte-for-byte copy, which doesn't seem consistent with this, but I'm not strongly opposed. |
| 18:39 | <Michael Ficarra> | I guess I slightly prefer it on the prototype |
| 18:41 | <Kris Kowal> | I’m leaning toward the prototype, given we’ve found precedent-founded names for a prototype-method, like setFromBase64. |
| 18:59 | <bakkot> | setFromBase64 seems as byte-for-byte as setInt32 does, to me? the input is not bytes itself, but can be represented by bytes in a canonical way, so you represent it as bytes and then set those in the buffer |
| 20:29 | <Kris Kowal> | I would not be offended by setFromHex, setFromAscii, or setFromUtf8 if they were proposed. There’s some bytewise compaction and contraction, not even uniformly proportional in all these cases. |
| 21:00 | <bakkot> | this proposal will include setFromHex |
| 21:01 | <bakkot> | fromUtf8 will continue to live in TextEncoder; no reason to be duplicative |
| 22:27 | <Kris Kowal> | Point made only to express comfort with set over write even for input of heterogenous width |