3 ms·

One thing I never really figured out with Sorbet is how it would work if I wanted to distribute a gem with type checked code. A typed gem would necessarily have

One thing I never really figured out with Sorbet is how it would work if I wanted to distribute a gem with type checked code. A typed gem would necessarily have to depend on the sorbet gem. Wouldn't this mean library users have no choice but to opt into type checks always being run in this library? (Is this why sorbet-runtime exists?)

vidarh 6y ago
You can sort that out easily by doing something like: module T module Sig def sig *args end end # You'd need to stub out a few more things here. end begin require 'sorbet-runtime' rescue LoadError end Basically as far as what I can tell from just having briefly looked at Sorbet, you could quite easily stub out the bare minimum to allow people to choose whether to pull in the full thing or not. It'd be nice if they provided a gem that did that.
rattray 6y ago
Yeah, the gem would depend on sorbet-runtime, and the library author could configure sorbet to not run any checks in production if desired (or to have any errors log instead of throw). You can configure things like this globally and/or for each method call. Eg; # turn off all runtime checks T::Configuration.default_checked_level = :never # turn off runtime checks for one method sig {returns(String).checked(:never)} def foo; :wont-raise; end Docs are here: https://sorbet.org/docs/runtime#runtime-checked-sigs https://sorbet.org/docs/runtime#runtime-checked-sigs Personally if I were authoring a gem I'd leave the runtime checks on except in hot paths, so my users get quick feedback when they pass the wrong thing. In any case, the library author can get the benefits of static and runtime typing, and their users will get nice static typing if they use sorbet. Users also get nice runtime typing for the library if the author chooses to leave it on for them. The overhead is usually small.

vidarh 6y ago

You can sort that out easily by doing something like: module T module Sig def sig *args end end # You'd need to stub out a few more things here. end begin require 'sorbet-runtime' rescue LoadError end Basically as far as what I can tell from just having briefly looked at Sorbet, you could quite easily stub out the bare minimum to allow people to choose whether to pull in the full thing or not. It'd be nice if they provided a gem that did that.

rattray 6y ago

Yeah, the gem would depend on sorbet-runtime, and the library author could configure sorbet to not run any checks in production if desired (or to have any errors log instead of throw). You can configure things like this globally and/or for each method call. Eg; # turn off all runtime checks T::Configuration.default_checked_level = :never # turn off runtime checks for one method sig {returns(String).checked(:never)} def foo; :wont-raise; end Docs are here: https://sorbet.org/docs/runtime#runtime-checked-sigs https://sorbet.org/docs/runtime#runtime-checked-sigs Personally if I were authoring a gem I'd leave the runtime checks on except in hot paths, so my users get quick feedback when they pass the wrong thing. In any case, the library author can get the benefits of static and runtime typing, and their users will get nice static typing if they use sorbet. Users also get nice runtime typing for the library if the author chooses to leave it on for them. The overhead is usually small.