4 ms·

> 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 "

> 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".
  - Joker_vD 2y ago
    > 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. Surely that's not the first time you've heard of run-time type casts? Well, in any case, they are colloquially called "type casts" and/or "type conversions". To be more pedantic, Java calls it "casting conversion" [0] which, in this specific case, allows one of the "narrowing reference conversion" [1] to happen. Go calls their version "type assertion" [2] but if you read what it actually does ("If T is an interface type, x.(T) asserts that the dynamic type of x implements the interface T") and compare with what Java does ("Such conversions require a test at run time to find out whether the actual reference value is a legitimate value of the new type"), I hope you would agree they are essentially the same. We can also take a look at C# [3]: it has "cast expressions" which work like this: "A cast-expression of the form (T)E, where T is a type and E is a unary-expression, performs an explicit conversion (§13.2) of the value of E to type T". And in this example, the exact kind of conversion to be performed would be 13.2.3, "Explicit reference conversions" for which the following is stated: "The explicit reference conversions are those conversions between reference-types that require run-time checks to ensure they are correct". So TFA could be written in any of those languages (or even in C++ with its dynamic_cast<T>) and look almost exactly the same because all TFA does it takes some objects, converts them up to Object type that subsumes all other types (in Golang's case, this type is called "any"), then tries to convert them down to some interface types which those objects may or may not implement, and blows up. But neither Java, C#, nor C++ have neither structural nor duck typing so TFA's claim that somehow this example shows that Go has duck or structural typing is simply baseless. [0] https://docs.oracle.com/javase/specs/jls/se6/html/conversions.html#5.5 https://docs.oracle.com/javase/specs/jls/se6/html/conversion... [1] https://docs.oracle.com/javase/specs/jls/se6/html/conversions.html#25379 https://docs.oracle.com/javase/specs/jls/se6/html/conversion... [2] https://go.dev/ref/spec#Type_assertions https://go.dev/ref/spec#Type_assertions [3] https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf
    - randomdata 2y ago
      > Surely that's not the first time you've heard of run-time type casts? Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer says in a language "just trust me on what type this is, don't bother to check my claim". A runtime type cast doesn't make any sense. I mean, I'm fine with words evolving and whatnot. I'm not here actually trying to play language police myself. But, as it seems you want to squabble over "duck type", which is then quite humorous when you accept any random definition someone can dream up for "cast": Why not call what Java is doing duck typing? > I hope you would agree they are essentially the same. I do agree, just as I said before, that Go's type conversions are essentially the same, except checked at compile time rather than run time. There is no conversion with type assertions, however. It is merely a runtime type check. The type you have is the type you keep. Now, what is important to remember is that Go's interface is a structural type. And what is a "structural type" checked at run time? That's right: A duck type! > So TFA could be written in any of those languages It's all just 1s and 0s at the end of the day. Of course you can write something that achieves the same result in just about any language. There is more nuance at play here, though. In the case of Go, it is not "here is another way to achieve the same thing". It literally employs duck typing, as duck typing is normally understood.

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".
- Joker_vD 2y ago
  > 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. Surely that's not the first time you've heard of run-time type casts? Well, in any case, they are colloquially called "type casts" and/or "type conversions". To be more pedantic, Java calls it "casting conversion" [0] which, in this specific case, allows one of the "narrowing reference conversion" [1] to happen. Go calls their version "type assertion" [2] but if you read what it actually does ("If T is an interface type, x.(T) asserts that the dynamic type of x implements the interface T") and compare with what Java does ("Such conversions require a test at run time to find out whether the actual reference value is a legitimate value of the new type"), I hope you would agree they are essentially the same. We can also take a look at C# [3]: it has "cast expressions" which work like this: "A cast-expression of the form (T)E, where T is a type and E is a unary-expression, performs an explicit conversion (§13.2) of the value of E to type T". And in this example, the exact kind of conversion to be performed would be 13.2.3, "Explicit reference conversions" for which the following is stated: "The explicit reference conversions are those conversions between reference-types that require run-time checks to ensure they are correct". So TFA could be written in any of those languages (or even in C++ with its dynamic_cast<T>) and look almost exactly the same because all TFA does it takes some objects, converts them up to Object type that subsumes all other types (in Golang's case, this type is called "any"), then tries to convert them down to some interface types which those objects may or may not implement, and blows up. But neither Java, C#, nor C++ have neither structural nor duck typing so TFA's claim that somehow this example shows that Go has duck or structural typing is simply baseless. [0] https://docs.oracle.com/javase/specs/jls/se6/html/conversions.html#5.5 https://docs.oracle.com/javase/specs/jls/se6/html/conversion... [1] https://docs.oracle.com/javase/specs/jls/se6/html/conversions.html#25379 https://docs.oracle.com/javase/specs/jls/se6/html/conversion... [2] https://go.dev/ref/spec#Type_assertions https://go.dev/ref/spec#Type_assertions [3] https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf https://www.itu.dk/people/sestoft/ecma/Ecma-334.pdf
  - randomdata 2y ago
    > Surely that's not the first time you've heard of run-time type casts? Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer says in a language "just trust me on what type this is, don't bother to check my claim". A runtime type cast doesn't make any sense. I mean, I'm fine with words evolving and whatnot. I'm not here actually trying to play language police myself. But, as it seems you want to squabble over "duck type", which is then quite humorous when you accept any random definition someone can dream up for "cast": Why not call what Java is doing duck typing? > I hope you would agree they are essentially the same. I do agree, just as I said before, that Go's type conversions are essentially the same, except checked at compile time rather than run time. There is no conversion with type assertions, however. It is merely a runtime type check. The type you have is the type you keep. Now, what is important to remember is that Go's interface is a structural type. And what is a "structural type" checked at run time? That's right: A duck type! > So TFA could be written in any of those languages It's all just 1s and 0s at the end of the day. Of course you can write something that achieves the same result in just about any language. There is more nuance at play here, though. In the case of Go, it is not "here is another way to achieve the same thing". It literally employs duck typing, as duck typing is normally understood.