4 ms·

Thanks I hate it. I wish it was part of the same file, it's very tricky to keep two files in sync especially during early development, and in a mature project

by syspec 6y ago

Thanks I hate it. I wish it was part of the same file, it's very tricky to keep two files in sync especially during early development, and in a mature project it becomes a chore. I thought most languages were moving away from header files. I know typescript has similar files but that is out of necessity as it is added to a language that has no idea typescript exists

wfleming 6y ago
I basically stopped paying attention to the progress of this feature when it was announced it would use header files. I don't expect I'll use it. I think it might be worth the headache with libraries - I think type errors are more useful when you cross the boundary into someone else's code. They're still useful within apps, of course, but personally I don't think I hit them often enough to make the headaches of a separate file worthwhile. My hope is that this is primarily motivated by wanting to maintain backwards compatibility for source, and maybe as more of the ruby ecosystem moves to 3.x future versions will add an alternative way of doing type annotations inline.
chrisjs95 6y ago
Couldn't we have a project that generated .rbs files from comments?
- riffraff 6y ago
  we could, and we do https://github.com/AaronC81/sord https://github.com/AaronC81/sord
Lio 6y ago
In most ruby projects we already maintain two files for every class; the class itself and its matching test/spec. Something I've wondered about rbs files since I first heard about them is, can we combine rbs descriptions with our unit tests? That would seem to make sense to me and help support TDD/BDD. Otherwise I'd probably stick to Sorbet in-line type definitions for ruby.
maxfurman 6y ago
There are a few reasons this wouldn't work for Ruby, mainly the reliance on metaprogramming in some of the more popular libraries. For example, the ORM ActiveRecord reads the database schema at runtime and generates the getters and setters for each column for the appropriate class. The class itself doesn't have any code listing these columns. Where would the inline annotation go?
- nerdponx 6y ago
  You can do this in Python as well, see SQLAlchemy's "reflection" capability for instance. You can even generate annotations at runtime if you wanted to (but there wouldn't be much point). I'm pretty confused as to why you would want to have annotations baked into your source code anyway, if you are reading the database schema at runtime.
  - maxfurman 6y ago
    For static analysis, you'd want to know that foo.col_a is an integer, foo.col_b is a string that might be null, and foo.col_c is not valid.
    - nerdponx 6y ago
      I know that, but are you going to read the database schema at "analysis time", i.e. before runtime and likely in a totally different environment from the runtime environment? IMO "reading the database schema at runtime" and "ahead-of-time static typing" are incompatible desires, except in a language that supports runtime access to the type checker.
- anamexis 6y ago
  The inline annotation could go anywhere you want it to - in the Rails model example, in the model file. You just need a way to declare methods without defining them.

by syspec 6y ago

wfleming 6y ago

I basically stopped paying attention to the progress of this feature when it was announced it would use header files. I don't expect I'll use it. I think it might be worth the headache with libraries - I think type errors are more useful when you cross the boundary into someone else's code. They're still useful within apps, of course, but personally I don't think I hit them often enough to make the headaches of a separate file worthwhile. My hope is that this is primarily motivated by wanting to maintain backwards compatibility for source, and maybe as more of the ruby ecosystem moves to 3.x future versions will add an alternative way of doing type annotations inline.

chrisjs95 6y ago

Couldn't we have a project that generated .rbs files from comments?

riffraff 6y ago
we could, and we do https://github.com/AaronC81/sord https://github.com/AaronC81/sord

Lio 6y ago

In most ruby projects we already maintain two files for every class; the class itself and its matching test/spec. Something I've wondered about rbs files since I first heard about them is, can we combine rbs descriptions with our unit tests? That would seem to make sense to me and help support TDD/BDD. Otherwise I'd probably stick to Sorbet in-line type definitions for ruby.

maxfurman 6y ago

There are a few reasons this wouldn't work for Ruby, mainly the reliance on metaprogramming in some of the more popular libraries. For example, the ORM ActiveRecord reads the database schema at runtime and generates the getters and setters for each column for the appropriate class. The class itself doesn't have any code listing these columns. Where would the inline annotation go?

nerdponx 6y ago
You can do this in Python as well, see SQLAlchemy's "reflection" capability for instance. You can even generate annotations at runtime if you wanted to (but there wouldn't be much point). I'm pretty confused as to why you would want to have annotations baked into your source code anyway, if you are reading the database schema at runtime.
- maxfurman 6y ago
  For static analysis, you'd want to know that foo.col_a is an integer, foo.col_b is a string that might be null, and foo.col_c is not valid.
  - nerdponx 6y ago
    I know that, but are you going to read the database schema at "analysis time", i.e. before runtime and likely in a totally different environment from the runtime environment? IMO "reading the database schema at runtime" and "ahead-of-time static typing" are incompatible desires, except in a language that supports runtime access to the type checker.
anamexis 6y ago
The inline annotation could go anywhere you want it to - in the Rails model example, in the model file. You just need a way to declare methods without defining them.