Humans do not have an algorithmic shortcut for parsing if it's hard for the machine, it's hard for the human.įor short chunks of program text, we can probably rely on our natural language abilities to some extent.
Which is, I would say, significante support. The support seems to be that, at a minimum, that it will have a standard for type definitions and provide them for Core and Stdlib and have command line tooling for working with type definitions. > Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code That's probably cleaner than further cluttering Ruby’s syntax with annotations.
If you mean you want type signatures embedded in code source files rather than in separate files, they seem to be taken a documentation-annotation approach, with YARD documentation format expressly called out as a mechanism to bed typing in source files. That’s sounds like what type-profiler, mentioned in the article, is for it's an experimental project which,if successful, seems destined to be part of Ruby’s bundled command line tooling, for generating type signatures from code. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code. > On the other hand, RBS as hand-written seems rather dangerous, to me. I might be missing a piece of the full puzzle not covered in the blog post, however. Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code, and instead will focus on external type checking. Sorbet cleverly (and unsurprisingly, given it's Ruby) used a DSL for definitions in code, which had the (excellent) additional boost of runtime checking, so you actually could know whether your types were accurate - by far the biggest pain-point of erased-type systems like TypeScript. On the other hand, RBS as hand-written seems rather dangerous, to me. This was a big problem for Flow, and why it lost the fight as soon as TypeScript's definitely-typed repository started gaining momentum - users wanted to use the type-checker that they knew had definitions for the libraries they used. d.ts file - as that allows for different type checking implementations to use the same system under the hood. It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a. Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe.
0 kommentar(er)
