7 ms·
> I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable t
by josephg 3y ago
> I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial inputs
Fight me.
Javascript has a separate TextDecoderStream class if you want to support chunked, partial inputs. The TextDecoder class doesn't support streaming input at all. And it never will, thanks to the existence of TextDecoderStream.
TextDecoder only provides 1 method - TextDecoder.decode(). And the method is pure! So you could just make it a global method without any loss of functionality. The entire class has no mutable state whatsoever. Its just a container for some options, passed into the constructor. Those options could just have been passed straight to a global decode() method.
https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder
This might be idiomatic C++, but its terrible javascript. I had a friend who worked on the Chrome team years ago. He said a lot of the browser engineers who design javascript APIs are C++ programmers who don't know javascript properly. So of course they port C++ ideas into javascript directly. They don't know any better. This is why javascript's standard library is an incoherent mess.
- tcfhgj 3y agoI see a benefit from having this options container: you can have a central place to set the options and then only pass down the decoder and the user of the function doesn't have to bother with the configuration
- wruza 3y agoYou can always pass a closure.
- tcfhgj 3y agoWell, that's basically the same
- josephg 3y agoOr pass an options object. Regardless, it’s a strictly worse api in the general case. And it’s on par with passing around an options object in the case you want to share the same options in multiple places. If the current api is either the same or worse compared to a pure function version in all cases, I’d prefer the pure function version thanks.
- tcfhgj 3y agoAn Options object is a worse API, since it assumes an implicit dependency. > If the current api is [...] the same [...] compared to a pure function version in all cases, I’d prefer the pure function version thanks. Why?
- josephg 3y ago> An Options object is a worse API, since it assumes an implicit dependency. No, it would be an explicit dependency. // definition: function decodeText(input, [format | options]) // use: decodeText(someBuffer, 'utf8') // or: const opts = {encoding: 'utf8', fatal: true, ignoreBOM: false} decodeText(someBuffer, opts) decodeText(somethingElse, opts) > Why? Because a pure function is idiomatic, concise and clear. Its easier to use, easier to document and easier to understand. The only benefit of a class is that it encapsulates its state behind an interface. That makes sense for a BTree or a database. But TextDecoder has no mutable state. It has no state at all except for its passed-in configuration. Decoding text is a verb not a noun. In programming, verbs are translated to functions, not classes. You don't have an "adder object" to add things. You don't have to instantiate a JSON stringifier before calling JSON.stringify. If thats not obvious, you may have spent too long in OO languages.