| 00:03 | <bakkot> | ehhh... I feel like the dataview methods only tend to make sense when you have data of mixed types in a buffer, and I don't think that's very likely for Uint8ClampedArray data |
| 00:04 | <bakkot> | wouldn't be opposed though |
| 05:06 | <ljharb> | any reason not to have the get tho also, for consistency? |
| 05:23 | <bakkot> | I feel like it is misleading? or like... allows people who are confused to lean into their confusion instead of discovering it |
| 05:24 | <bakkot> | it is better to notice what you are doing and just use getUint8 if you actually want it |
| 05:24 | <bakkot> | if someone reaches for it and it's not there, and then they stop and think about why that is, that's good |
| 06:14 | <leftmostcat> | I think it's rare that toolboxes are complete enough that most devs will think, "Should I not be doing this?" if the tool is missing, so that intent would need to be well-documented. |
| 12:50 | <littledan> | I think Clamped is good to leave out; it is just some weird canvas legacy |
| 15:37 | <ljharb> | it’s there everywhere else tho |
| 17:21 | <ljharb> | ok well i made https://github.com/ljharb/proposal-dataview-get-set-uint8c and put it on the agenda, we can see what everyone thinks :-) |
| 17:26 | <Michael Ficarra> | the get method makes me pretty uncomfortable |
| 17:27 | <ljharb> | why? |
| 17:34 | <Michael Ficarra> | because it's no different than the regular Uint8 getter |
| 17:34 | <Michael Ficarra> | and someone will be confused by its existence |
| 17:36 | <ljharb> | seems like just part of the confusion of Uint8ClampedArray existing itself |
| 17:38 | <bakkot> | It is kind of weird that Uint8ClampedArray exists, but it at least does a coherent, non-duplicative thing |
| 17:39 | <bakkot> | but getUint8Clamped would be duplicative |
| 17:40 | <ljharb> | [0] on a Uint8Array and Uint8ClampedArray is duplicative too, no? |
| 17:41 | <ljharb> | adding the set without the get is still improving consistency imo, but i really don't see the harm here of having it be duplicative. |
| 17:43 | <bakkot> |
... no? I mean if you have a Uint8ClampedArray you do need to be able to read from it |
| 17:46 | <ljharb> | right but i mean that there's no difference in reading values from both of the uint8 arrays |
| 17:47 | <bakkot> | yes but you can't provide Uint8ClampedArray without the ability to read from it |
| 17:47 | <bakkot> | so it does not make sense to say that [0] is duplicative |
| 17:47 | <bakkot> | "ability to read from a Uint8Array" and "ability to read from a Uint8ClampedArray" are distinct operations even though they implement the same logic |
| 17:48 | <bakkot> | but "read a Uint8 from an ArrayBuffer" is not a distinct operation from "read a Uint8Clamped from an ArrayBuffer" |
| 17:48 | <ljharb> | fair |
| 17:48 | <ljharb> | the current state means i have to special-case my code that dynamically builds the dataview method name, because Uint8C isn't there |
| 17:48 | <ljharb> | so for me, having it missing is what's confusing |
| 17:50 | <bakkot> | I think that case is probably pretty niche |
| 17:52 | <ljharb> | sure, but i'd bet in a similar bucket of niche as using the dataview methods at all |
| 18:49 | <rbuckton> | Just for Uint8 or in general? ar[0] uses native endianness. dataView.get* and dataView.set* use big-endian/native byte order by default, and allows you to specify little-endian if needed, so they're pretty useful for decoding binary-format files without having to detect endianness and adjust manually |
| 18:50 | <ljharb> | fair, altho i think that's not a common use case :-) |
| 18:50 | <ljharb> | not saying they're not useful, just not common |
| 18:50 | <ljharb> | the ability to specify endianness is why i'm using them |
| 18:51 | <rbuckton> | I would venture to guess folks using web sockets would disagree that it's not common. |
| 19:07 | <Michael Ficarra> | anybody processing any binary network protocols, really |
| 19:38 | <rbuckton> | Of course, then there's me, using DataView to parse a PE header to find the base address of a Windows executable (which are encoded in little-endian)... |