5 ms·

Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its i

Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its interfaces (a type implements an interface if it implements its methods, so we can use interface as function parameter type). I don't get why we talk of duck typing about ruby : if I pass as parameter an object that does not quack like a duck, nothing will prevent me to do it and it will generate an exception when quacking. Did I miss something obvious?

vidarh 8y ago
The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirements of dosomething(), the class of "source" is irrelevant. The relevant type information is whether or not "source" responds to "shift". A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby.
- oelmekki 8y ago
  I've digged a bit on the subject (better late than never), it seems that duck typing is seen in ruby as a guideline, rather than a language feature. Basically, it's about recommending to use `#respond_to?` rather than `#is_a?`, `#kind_of?` or `Class#===` in end user code.
  - vidarh 8y ago
    It's a language feature in as much as the absence of static typing and the ability to check for methods is what makes it possible. But yes, it it a guideline, and Ruby code that violates it will generally be seen as not being idiomatic Ruby.
    - oelmekki 8y ago
      Oh, I see, given the interpreter is written in strongly typed language, allowing to go without static typing is a feature by itself, and allowing to test for methods presence allows to do duck typing, thus it allows to say that ruby implements duck typing. It makes more sense than talking of duck typing explicit usage by end users, given it's quite rare we assert proper received parameters extensively. EDIT : which makes me realize we have a machine language without typing (binary), on top of which we use a language implementing strong typing (C), used to build a language without strong typing (ruby), on top of which Stripe is building strong typing. Making a definitive decision is hard :)
      - mdpye 8y ago
        Nitpick: C is weakly typed, Ruby is strong. C is statically typed, Ruby is dynamic. Strong typing is about objects having a definite type. In Ruby, you cannot cast a String to a Fixnum, an exception will be raised. But in C you may cast anything to anything really, and your program will believe you, whether it could possibly make sense or not...
        oelmekki 8y ago
        I thought "strong typing" and "static typing" were interchangeable. I stand corrected, thanks.
- ninkendo 8y ago
  I wonder if this would be a good opportunity to use a typing system that's more like Go's, where you don't need to explicitly declare that a class implements an interface, but instead any class that has the right methods will implement the right interfaces automatically. (In your example the method could be: def foo(source: Shiftable<?>) dosomething(source.shift) end where `Shiftable` is an interface that's something like iface Shiftable<T> .shift(): T end )
- emodendroket 8y ago
  > A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby. It probably won't be idiomatic (maybe just add interfaces?) but I think duck-typing is overrated anyway. Just because an object responds to a method doesn't mean it's going to do anything like what you expect. To take a contrived example, Array.Shift and Keyboard.Shift are probably unrelated methods.
  - vidarh 8y ago
    You don't have that guarantee with interfaces either - you're trusting that the developer isn't lying to you. My experience is that I've more often run into developers that have artificially barred me from doing what I wanted by checking for a given class, than that I've accidentally passed in something that satisfies a given type but does something different.
    - klmr 8y ago
      > You don't have that guarantee with interfaces either True, but you can give the interfaces/contracts proper names (or namespaces). To use the example in the parent comment, `Array` and `Keyboard` wouldn’t implement the same contract even if both have a `Shift` method.
  - emodendroket 8y ago
    I guess now that I think about it Scala does have a strongly-typed duck-typing thing, but it's kind of silly and rarely used.

vidarh 8y ago

The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirements of dosomething(), the class of "source" is irrelevant. The relevant type information is whether or not "source" responds to "shift". A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby.

oelmekki 8y ago
I've digged a bit on the subject (better late than never), it seems that duck typing is seen in ruby as a guideline, rather than a language feature. Basically, it's about recommending to use `#respond_to?` rather than `#is_a?`, `#kind_of?` or `Class#===` in end user code.
- vidarh 8y ago
  It's a language feature in as much as the absence of static typing and the ability to check for methods is what makes it possible. But yes, it it a guideline, and Ruby code that violates it will generally be seen as not being idiomatic Ruby.
  - oelmekki 8y ago
    Oh, I see, given the interpreter is written in strongly typed language, allowing to go without static typing is a feature by itself, and allowing to test for methods presence allows to do duck typing, thus it allows to say that ruby implements duck typing. It makes more sense than talking of duck typing explicit usage by end users, given it's quite rare we assert proper received parameters extensively. EDIT : which makes me realize we have a machine language without typing (binary), on top of which we use a language implementing strong typing (C), used to build a language without strong typing (ruby), on top of which Stripe is building strong typing. Making a definitive decision is hard :)
    - mdpye 8y ago
      Nitpick: C is weakly typed, Ruby is strong. C is statically typed, Ruby is dynamic. Strong typing is about objects having a definite type. In Ruby, you cannot cast a String to a Fixnum, an exception will be raised. But in C you may cast anything to anything really, and your program will believe you, whether it could possibly make sense or not...
      - oelmekki 8y ago
        I thought "strong typing" and "static typing" were interchangeable. I stand corrected, thanks.
ninkendo 8y ago
I wonder if this would be a good opportunity to use a typing system that's more like Go's, where you don't need to explicitly declare that a class implements an interface, but instead any class that has the right methods will implement the right interfaces automatically. (In your example the method could be: def foo(source: Shiftable<?>) dosomething(source.shift) end where `Shiftable` is an interface that's something like iface Shiftable<T> .shift(): T end )
emodendroket 8y ago
> A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby. It probably won't be idiomatic (maybe just add interfaces?) but I think duck-typing is overrated anyway. Just because an object responds to a method doesn't mean it's going to do anything like what you expect. To take a contrived example, Array.Shift and Keyboard.Shift are probably unrelated methods.
- vidarh 8y ago
  You don't have that guarantee with interfaces either - you're trusting that the developer isn't lying to you. My experience is that I've more often run into developers that have artificially barred me from doing what I wanted by checking for a given class, than that I've accidentally passed in something that satisfies a given type but does something different.
  - klmr 8y ago
    > You don't have that guarantee with interfaces either True, but you can give the interfaces/contracts proper names (or namespaces). To use the example in the parent comment, `Array` and `Keyboard` wouldn’t implement the same contract even if both have a `Shift` method.
- emodendroket 8y ago
  I guess now that I think about it Scala does have a strongly-typed duck-typing thing, but it's kind of silly and rarely used.