4 ms·

> Do those languages now have duck typing Maybe. I don't have a language reference handy. Does runtime type checking take place with that code? My impression,

> Do those languages now have duck typing Maybe. I don't have a language reference handy. Does runtime type checking take place with that code? My impression, based on the way you said it (and my vague memories of using Java once upon a time), is no. On that assumption, where would you find the duck type? The significance of both structural typing and duck typing is that type checking occurs. As before, the difference is when the check takes place – be it at compile time or at runtime. Perhaps you could update that code to demonstrate how you would bypass calling objects which, when type checked, show to not quack like a duck like as is shown in the Go examples?

dilap 2y ago
I think the closest equivalent in Java or C# would be to use reflection to pull out the Swim and Quack methods.
- mseepgood 2y ago
  In C# you would simply use the 'dynamic' keyword.
  - neonsunset 2y ago
    And get yelled at by your colleagues ;D In practice, the use of dynamic is highly discouraged as well as anything that could lead to type confusion i.e. currently discussed Go's duck typing it calls structural (runtime vs static is impl. detail). Instead, you are expected to simply do 'lessSpecific is IMoreSpecific ms`, works particularly well with pattern matching on switches for functional style.
  - dilap 2y ago
    ha totally forgot about that! what a crazy feature. i wonder if anyone uses it in the wild?
Joker_vD 2y ago
Yes, the runtime type check does happen, see [0]. The output is pretty much the same as with the Go example, only the exact wording of the exception/panic is different. And no, the structural/duck typing is not about when the type checking happens. It's about not having to write "implements IDuck" right in the class declaration for the down-cast to succeed. [0] https://godbolt.org/z/vndns4619 https://godbolt.org/z/vndns4619
- randomdata 2y ago
  > It's about not having to write "implements IDuck" right in the class declaration for the down-cast to succeed. That doesn't make sense. Not having to write "implements IDuck" is true of both structural typing and duck typing. That logically cannot be what makes them different.
  - Joker_vD 2y ago
    Sorry, apparently we literally can't understand each other. I write "the structural/duck typing is not about [X], it's about not having to write "implements IDuck", and you reply with "that doesn't make sense. Not having to write "implements IDuck" is true of both structural typing and duck typing". My original point was that TFA doesn't really feature duck/structural typing; the example program just shows dynamic upcasting/downcasting, which has been a staple of OOP since forever, and has no relation to duck/structural typing.
    - randomdata 2y ago
      > I write "the structural/duck typing is not about [X] The structural/duck typing thing is exactly about when the type check happens. That is the thing that makes them different. We aren't just throwing out random words. We would not be talking about them in the first place if not for that fact. To say it is not about the only reason we have for talking about them is... strange. > My original point was that TFA doesn't really feature duck/structural typing It does, indeed. It demonstrates both, in fact. Go uses nominal typing for everything but interfaces. Is that the source your confusion? > the example program just shows dynamic upcasting/downcasting I know we threw casting around loosely to not confuse the contextual parent, but if you look closely, Go doesn't even support casting at all. And this isn't type conversion either. Go uses the syntax `type(variable)` for that. This really has nothing to do with what was seen in the article; it was doing something quite different. To be fair, I'm not sure you have demonstrated that Java has casting either. What you wrote appears to be much more like type conversion, except type conversion is checked statically, while yours was checked at runtime. Frankly, I have never heard of a term for what you have shown, so I don't know what to call it. I suppose casting, overloaded with new meaning, really is that term[1]? Go doesn't support casting in that sense either, though. [1] Which, if that is the case, would make the rest of this thread quite hilarious with your attempt to be the language police for "duck type", yet being accepting of any arbitrary use of "cast".

dilap 2y ago

I think the closest equivalent in Java or C# would be to use reflection to pull out the Swim and Quack methods.

mseepgood 2y ago
In C# you would simply use the 'dynamic' keyword.
- neonsunset 2y ago
  And get yelled at by your colleagues ;D In practice, the use of dynamic is highly discouraged as well as anything that could lead to type confusion i.e. currently discussed Go's duck typing it calls structural (runtime vs static is impl. detail). Instead, you are expected to simply do 'lessSpecific is IMoreSpecific ms`, works particularly well with pattern matching on switches for functional style.
- dilap 2y ago
  ha totally forgot about that! what a crazy feature. i wonder if anyone uses it in the wild?

Joker_vD 2y ago

Yes, the runtime type check does happen, see [0]. The output is pretty much the same as with the Go example, only the exact wording of the exception/panic is different. And no, the structural/duck typing is not about when the type checking happens. It's about not having to write "implements IDuck" right in the class declaration for the down-cast to succeed. [0] https://godbolt.org/z/vndns4619 https://godbolt.org/z/vndns4619

randomdata 2y ago
> It's about not having to write "implements IDuck" right in the class declaration for the down-cast to succeed. That doesn't make sense. Not having to write "implements IDuck" is true of both structural typing and duck typing. That logically cannot be what makes them different.
- Joker_vD 2y ago
  Sorry, apparently we literally can't understand each other. I write "the structural/duck typing is not about [X], it's about not having to write "implements IDuck", and you reply with "that doesn't make sense. Not having to write "implements IDuck" is true of both structural typing and duck typing". My original point was that TFA doesn't really feature duck/structural typing; the example program just shows dynamic upcasting/downcasting, which has been a staple of OOP since forever, and has no relation to duck/structural typing.
  - randomdata 2y ago
    > I write "the structural/duck typing is not about [X] The structural/duck typing thing is exactly about when the type check happens. That is the thing that makes them different. We aren't just throwing out random words. We would not be talking about them in the first place if not for that fact. To say it is not about the only reason we have for talking about them is... strange. > My original point was that TFA doesn't really feature duck/structural typing It does, indeed. It demonstrates both, in fact. Go uses nominal typing for everything but interfaces. Is that the source your confusion? > the example program just shows dynamic upcasting/downcasting I know we threw casting around loosely to not confuse the contextual parent, but if you look closely, Go doesn't even support casting at all. And this isn't type conversion either. Go uses the syntax `type(variable)` for that. This really has nothing to do with what was seen in the article; it was doing something quite different. To be fair, I'm not sure you have demonstrated that Java has casting either. What you wrote appears to be much more like type conversion, except type conversion is checked statically, while yours was checked at runtime. Frankly, I have never heard of a term for what you have shown, so I don't know what to call it. I suppose casting, overloaded with new meaning, really is that term[1]? Go doesn't support casting in that sense either, though. [1] Which, if that is the case, would make the rest of this thread quite hilarious with your attempt to be the language police for "duck type", yet being accepting of any arbitrary use of "cast".