3 ms·
That's true. But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions.
by ssmoot 11y ago
That's true.
But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions.
Instances may be Strongly typed in Ruby. Methods are not. So you get almost none of the benefit. It's like Types only exist in Ruby to support Mixins and inheritance chains.
Prefer Composition over Inheritance right? But what if through Composition you effectively lost all your Type information? That's the issue Ruby presents.
- YorickPeterse 11y ago> Instances may be Strongly typed in Ruby. Methods are not. Sure they are, just not all of them: [].first('wat') # => TypeError: no implicit conversion of String into Integer What Ruby lacks is _static typing_ and compile time checks of these types. Instead we have runtime checks in a few places. > Prefer Composition over Inheritance right? But what if through Composition you > effectively lost all your Type information? That's the issue Ruby presents. This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour. For example: class MyArray < Array end m = MyArray.new([10, 20, 30]) p m.map { |number| number * 2 }.class # => Array Here one would probably expect an instance of MyArray to be returned, but instead we get a vanilla Array.
- oh_sigh 11y agoWhy would you expect that if you didn't implement map in MyArray?
- yxhuvud 11y ago> This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour No. It is advocated because it produces simpler code in the long term in most cases. It is a quite different question to inheritance from core classes.
- saraid216 11y agoUsing introspection in Ruby is generally against convention. There's no reason to care about the class name if it #responds_to? the method you care about calling.
- ssmoot 11y agoThat's not an example of a strongly typed method in Ruby. That's an example of an assertion (most likely implemented in C). Though in hindsight you're right anyways. Methods define an implicit type for the arguments they operate over. It's just you don't know what it is without reading the whole method. Which I think gets to "expressiveness".