3 ms·

Does this include writing libraries for use by third-parties?

by Yoric 4y ago

vidarh 4y ago
To an extent. In libraries for third parties you do need to test contracts specified by your docs, but a well written Ruby library should intentionally avoid over-testing typing (both in separate tests and in code) and focus on testing behaviours. Sure, test for sane failure modes in line with the documented contract, and that may include the occasional test that is de facto a type test, but often testing for types, especially in languages with poor type systems, but also in Ruby where we have alternatives, ends up with tests for classes which is frequently the wrong thing. E.g. in Ruby never, ever check for somearg.kind_of?(IO) if all you ever do is somearg.read - if you absolutely must typecheck somearg, the Ruby way is to check for presence of "#read", e.g. somearg.respond_to?(:read), or try and fail responsibly (and often just allowing the NoMethodError to bubble up is the right way to fail). Also think it's just fine for people to add and ship Sorbet type declarations for gems etc. to then signal those contracts so people can verify them if they choose. There's no reason not to offer that when it's reasonable to do so.
- Yoric 4y ago
  I have zero to no experience coding in Ruby, so I cannot comment in that case. In Python or JavaScript/TypeScript, though, my experience is that failing to validate types at the borders (i.e. every single function/method/constructor/generator/... exposed in your API) is pretty much guaranteed to end up, months later, with developers attempting to sherlock out surprising breakages in production from logs that make no sense and traces that do not show anything remotely close to the actual culprit. I have the scars to show it :) Of course, YMMV.
  - vidarh 4y ago
    The "Ruby way" in this respect tends to be to avoid being over-prescriptive. That doesn't mean "do no checks", but "do only the checks actually needed" with a very different expectation of "what is needed" than in many other languages. Hence don't check for an IO object when what you care about is the presence of a "#read" method. Or don't check if something is an Array if what matters is that it supports "#map". Instead, either somearg.respond_to?(:map), or if it needs more than map, somearg.respond_to?(Enumerable) (this seems broad, but supporting Enumerable only requires implementing "#each" and including the module, so a caller "worst case" can reopen a class or wrap their object), or call one of Array(somearg) (tries "#to_ary" then "#to_a" then falls back to returning [somearg]) or Array.try_convert(somearg) (tries "#to_ary" then falls back on nil). Consistently picking the most generic applicable options when faced with choices like that still enforces the contract on the boundary, but also tends to lead to code with much less ceremony. E.g. far fewer [something]Adapter classes, or glue code to convert data before calling methods that are being overly prescriptive. But for most statically typed languages, when people talk about static typing, they still talk about a class and a type as interchangeable (there are exceptions, and it's getting better, and with increased type inference coupled with increased support for type annotations and analysis of dynamic languages, I expect there to be an increasing convergence, though).
    - Yoric 4y ago
      This makes sense, although there are downsides to not naming types, as these serve as documentation. Python documentation has a strong tendency to using descriptions to avoid giving names to types, which imho makes the documentation needlessly confusing. Note that I'm writing "types" and not "classes". Interfaces do just as well, if not better! For what it's worth, in the static realm, OCaml introduce features that let code check for presence of a method (instead of implementing an interface) ~25 years ago. Unfortunately, this proved rather unwieldy and, to the best of my knowledge, nobody uses that feature.
      - vidarh 4y ago
        The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. When there is a meaningful name to give, in Ruby you might define a module, and include it and use that as an interface: module HelloWorld def hello raise "Not implemented" end end class Foo include HelloWorld end Foo.new.hello # Raises an exception Foo.new.kind_of?(HelloWorld) # Returns true (And anytime you want something that behaves somewhat like an ordered collection, you typically just want object.kind_of?(Enumerable)). There are plenty of contract-checking frameworks for Ruby [1] but they see little use, because most of our contracts tend to be extremely simple. Along the line of "implements method X" or "includes module Y". Sorbet w/inference tools and optionally storing the types in a separate files (it supports inline too) might slowly change that (and effectively let you use modules as "proper" interfaces), since the biggest opposition to types in Ruby tends to be visual noise and forcing refactoring, and if it can be turned on/off in your IDE and regenerated, a lot of the objections fall away. It's not that we (well many of us) don't want the extra type checks, but that we don't want to pay the cost of making the code less readable. [1] Here's one: http://egonschiele.github.io/contracts.ruby/ http://egonschiele.github.io/contracts.ruby/ and of course there's Sorbet: https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet
        Yoric 4y ago
        > The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. Do you have examples? That's not my experience. Of course, we may simply be working on very different types of code :)

Does this include writing libraries for use by third-parties?

by Yoric 4y ago

Does this include writing libraries for use by third-parties?

To an extent. In libraries for third parties you do need to test contracts specified by your docs, but a well written Ruby library should intentionally avoid over-testing typing (both in separate tests and in code) and focus on testing behaviours. Sure, test for sane failure modes in line with the documented contract, and that may include the occasional test that is de facto a type test, but often testing for types, especially in languages with poor type systems, but also in Ruby where we have alternatives, ends up with tests for classes which is frequently the wrong thing. E.g. in Ruby never, ever check for somearg.kind_of?(IO) if all you ever do is somearg.read - if you absolutely must typecheck somearg, the Ruby way is to check for presence of "#read", e.g. somearg.respond_to?(:read), or try and fail responsibly (and often just allowing the NoMethodError to bubble up is the right way to fail). Also think it's just fine for people to add and ship Sorbet type declarations for gems etc. to then signal those contracts so people can verify them if they choose. There's no reason not to offer that when it's reasonable to do so.

Yoric 4y ago
I have zero to no experience coding in Ruby, so I cannot comment in that case. In Python or JavaScript/TypeScript, though, my experience is that failing to validate types at the borders (i.e. every single function/method/constructor/generator/... exposed in your API) is pretty much guaranteed to end up, months later, with developers attempting to sherlock out surprising breakages in production from logs that make no sense and traces that do not show anything remotely close to the actual culprit. I have the scars to show it :) Of course, YMMV.
- vidarh 4y ago
  The "Ruby way" in this respect tends to be to avoid being over-prescriptive. That doesn't mean "do no checks", but "do only the checks actually needed" with a very different expectation of "what is needed" than in many other languages. Hence don't check for an IO object when what you care about is the presence of a "#read" method. Or don't check if something is an Array if what matters is that it supports "#map". Instead, either somearg.respond_to?(:map), or if it needs more than map, somearg.respond_to?(Enumerable) (this seems broad, but supporting Enumerable only requires implementing "#each" and including the module, so a caller "worst case" can reopen a class or wrap their object), or call one of Array(somearg) (tries "#to_ary" then "#to_a" then falls back to returning [somearg]) or Array.try_convert(somearg) (tries "#to_ary" then falls back on nil). Consistently picking the most generic applicable options when faced with choices like that still enforces the contract on the boundary, but also tends to lead to code with much less ceremony. E.g. far fewer [something]Adapter classes, or glue code to convert data before calling methods that are being overly prescriptive. But for most statically typed languages, when people talk about static typing, they still talk about a class and a type as interchangeable (there are exceptions, and it's getting better, and with increased type inference coupled with increased support for type annotations and analysis of dynamic languages, I expect there to be an increasing convergence, though).
  - Yoric 4y ago
    This makes sense, although there are downsides to not naming types, as these serve as documentation. Python documentation has a strong tendency to using descriptions to avoid giving names to types, which imho makes the documentation needlessly confusing. Note that I'm writing "types" and not "classes". Interfaces do just as well, if not better! For what it's worth, in the static realm, OCaml introduce features that let code check for presence of a method (instead of implementing an interface) ~25 years ago. Unfortunately, this proved rather unwieldy and, to the best of my knowledge, nobody uses that feature.
    - vidarh 4y ago
      The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. When there is a meaningful name to give, in Ruby you might define a module, and include it and use that as an interface: module HelloWorld def hello raise "Not implemented" end end class Foo include HelloWorld end Foo.new.hello # Raises an exception Foo.new.kind_of?(HelloWorld) # Returns true (And anytime you want something that behaves somewhat like an ordered collection, you typically just want object.kind_of?(Enumerable)). There are plenty of contract-checking frameworks for Ruby [1] but they see little use, because most of our contracts tend to be extremely simple. Along the line of "implements method X" or "includes module Y". Sorbet w/inference tools and optionally storing the types in a separate files (it supports inline too) might slowly change that (and effectively let you use modules as "proper" interfaces), since the biggest opposition to types in Ruby tends to be visual noise and forcing refactoring, and if it can be turned on/off in your IDE and regenerated, a lot of the objections fall away. It's not that we (well many of us) don't want the extra type checks, but that we don't want to pay the cost of making the code less readable. [1] Here's one: http://egonschiele.github.io/contracts.ruby/ http://egonschiele.github.io/contracts.ruby/ and of course there's Sorbet: https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet
      - Yoric 4y ago
        > The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. Do you have examples? That's not my experience. Of course, we may simply be working on very different types of code :)