3 ms·
> lack of static types RBS is a thing; we use it extensively. > Good luck finding where the `process` function is called from I don't use it like that but I
by lloeki 11mo ago
> lack of static types
RBS is a thing; we use it extensively.
> Good luck finding where the `process` function is called from
I don't use it like that but I seem to recall RBS itself has a query mechanism and can answer these kind of questions.
- IshKebab 11mo ago> we use it extensively Who is "we"? The Ruby projects I use are Asciidoctor and Gitlab and neither of them use it. Also putting types in a totally separate file is an abysmal UX.
- lloeki 11mo ago> Who is "we"? $dayjob; does it really matter who as long as it's an example of it being useful to someone? > putting types in a totally separate file is an abysmal UX. Is it though? I much prefer def frobz(fizbazbang) # ... the code to def frobz(Hash<Symbol | String | Integer, Array<String | Integer>> fizbazbang) -> Array<Hash<String | Integer, String>> fizbazbang # ... the code It's the job of the code editor to get that information surfaced to me at the proper place (e.g virtual content like vim inlay hints, hover tooltips, those vscode embeds or whatever they are called). If I need to jump quickly I have projections† set up. Having the types inline isn't that useful anyway as it gives yo only the signature but gives you no info of whatever type intermediate things are without much thinking. And interesting things happen when you have separate `.rbs` files: I started to develop some things type first then progressively fill the implementation in. † Well known because of https://github.com/tpope/vim-projectionist https://github.com/tpope/vim-projectionist but projections are not limited to vim.