3 ms·
> 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
by YorickPeterse 12y 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 12y agoWhy would you expect that if you didn't implement map in MyArray?
- yxhuvud 12y 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 12y 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 12y 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".