3 ms·
it's amazing to me that the industry hasn't found a better way to support bits of code interacting with other bits of code properly, than adding an attribute to
by uticus 1y ago
it's amazing to me that the industry hasn't found a better way to support bits of code interacting with other bits of code properly, than adding an attribute to a bit of code calling it a "type"
...saying this as someone who benefits from it but also rarely uses sub-typing ("poodle" type sub to "dog" type sub to "animal" type) or any sort of the other benefits that are commonly associated with typing. for me the benefit is code checking and code navigation of unfamiliar code bases
- xboxnolifes 1y agostructural typing? duck typing?
- uticus 1y agostructural typing is a good step - but afaik there's no way to distinguish between different types that have the same structure but different context - a "truth.right" will be different from a "direction.right", but it's up to the dev to keep that straight. duck typing is what ruby does without sorbet or rbs, it portrays nothing about how the code bits interact at the boundary. if a "dog" is passed in but a "cat" is expected, things will work just fine until runtime when the cat is asked to bark. (saying as someone who is a big fan of ruby overall)
- zhisme 1y agoWith great power comes great responsibility. It is developer responsibility to ensure that you will not receive cat during designing stage of your classes. And inheritance is bad, this is also sharp knife. But annotating everywhere sig { params(cat: Cat) } does not improve your design, it just makes noisy and clumsy. I would think that if your code need type annotations, it smells like bad design and should be considered for refactoring.