It’s interesting that the type information is to be kept in a kind of ‘signature’ file, separate from .rb code files.
I wonder why they’re not allowing it alongside existing code. Perhaps it can’t be done in a backwards-compatible way - or a non-messy way?
Elixir allows adding ‘typespecs’ above function definitions like this:
… where the choice of which function is called happens at runtime based on guards (first example) and/or pattern matching the arguments.
Ruby doesn’t have a mechanism like this (as far as I’m aware) or overloading (dynamic despatch based on type) so it would make more sense for arguments to have their types specified ‘inline’ - as shown in the example .rbs file.
Perhaps if the .rbs idea works, the next step could be to make the Ruby interpreter(s) allow an inline syntax?
The idea was to maximize flexibility and decouple the code from the typing. They must have been thinking along those lines given their support for interface types and what they call non-uniformity.
The nice thing is that what they have described looks forward-compatible with adding the type specs to the Ruby source eventually. On that day, there will likely be a tool to collapse .rbs types into class, field, and method definitions in .rb files.
That’s also what we do in CHICKEN; there’s inline syntax for types which gets used when compiling just that module, but the types then are exported into a “types database” file which gets consulted when compiling other code which uses the module.
It is also possible to supply a manually-written types file, which gets used when compiling other code against the module it corresponds to.
It’s interesting that the type information is to be kept in a kind of ‘signature’ file, separate from .rb code files. I wonder why they’re not allowing it alongside existing code. Perhaps it can’t be done in a backwards-compatible way - or a non-messy way?
Elixir allows adding ‘typespecs’ above function definitions like this:
Having the types specified in this way does work, but it’s a bit of a trade-off. Elixir code often looks like this:
Or this:
… where the choice of which function is called happens at runtime based on guards (first example) and/or pattern matching the arguments.
Ruby doesn’t have a mechanism like this (as far as I’m aware) or overloading (dynamic despatch based on type) so it would make more sense for arguments to have their types specified ‘inline’ - as shown in the example .rbs file.
Perhaps if the .rbs idea works, the next step could be to make the Ruby interpreter(s) allow an inline syntax?
I pitched the idea of a separate file a long time ago. ( https://www.artima.com/forums/flat.jsp?forum=106&thread=155960 ).
The idea was to maximize flexibility and decouple the code from the typing. They must have been thinking along those lines given their support for interface types and what they call non-uniformity.
The nice thing is that what they have described looks forward-compatible with adding the type specs to the Ruby source eventually. On that day, there will likely be a tool to collapse .rbs types into class, field, and method definitions in .rb files.
That’s also what we do in CHICKEN; there’s inline syntax for types which gets used when compiling just that module, but the types then are exported into a “types database” file which gets consulted when compiling other code which uses the module.
It is also possible to supply a manually-written types file, which gets used when compiling other code against the module it corresponds to.