3 ms·

I 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 func

by tcfhgj 3y ago

I 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 ago
You can always pass a closure.
- tcfhgj 3y ago
  Well, that's basically the same
- josephg 3y ago
  Or 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 ago
    An 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.

by tcfhgj 3y ago

wruza 3y ago

You can always pass a closure.

tcfhgj 3y ago
Well, that's basically the same
josephg 3y ago
Or 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 ago
  An 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.