3 ms·

I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have

I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the concept. Is there an other option that I'm not seeing?

drewgross 11y ago
In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.
- deleted 11y ago
  [deleted]
drewgross 11y ago
In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.
dllthomas 11y ago
Why aren't type classes the solution you're looking for?
- nrinaudo 11y ago
  I... don't actually understand why you would ask that question. How do type classes help, one way or the other, when the discussion is "duck typing cannot (always) be replaced in static languages by having various types extend a common interface. True or false?". They allow you do something else, something I would argue is better (and I explicitly said so, "The best solution I know of is type classes, in languages that support them."), but are entirely irrelevant to sanderjd's point and my answer.
  - dllthomas 11y ago
    I know you mentioned type classes (repeatedly and positively). What I mean is that I don't see why, in their presence, there's still a problem. On careful reread, I guess you don't see them as an example of "having various types extend a common interface"? (which would make them a solution, but excluded from the discussion) (edited to add - and I find that description to fit them just find, hence my confusion)
    - nrinaudo 11y ago
      That's exactly it: they're a good solution to the problem, but since type classes work specifically by avoiding subtype polymorphism (and are instead a mix of parametric and ad hoc polymorphism), they cannot be part of a discussion that is centered on whether or not subtype polymorphism is a good fit. But, yes. The more I code, the more it feels like type classes are never not a good answer.
      - dllthomas 11y ago
        The thing is, I don't see anything actually restricting the scope of discussion to subtype polymorphism. "The more I code, the more it feels like type classes are never not a good answer." As they are used in Haskell, they sometimes get awkward where you where multiple instances are relevant to the same data in the same scope. You can newtype cast around, but I've been wondering (with multiparameter typeclasses) if reifying the instance we care about is 1) useful, and 2) actually still distinct from explicitly passing the dictionary as a record. Regarding 1, I've consistently leaned "yes", although without tremendous confidence. Regarding 2, I've gone back and forth over time.

drewgross 11y ago

In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.

deleted 11y ago
[deleted]

drewgross 11y ago

dllthomas 11y ago

Why aren't type classes the solution you're looking for?

nrinaudo 11y ago
I... don't actually understand why you would ask that question. How do type classes help, one way or the other, when the discussion is "duck typing cannot (always) be replaced in static languages by having various types extend a common interface. True or false?". They allow you do something else, something I would argue is better (and I explicitly said so, "The best solution I know of is type classes, in languages that support them."), but are entirely irrelevant to sanderjd's point and my answer.
- dllthomas 11y ago
  I know you mentioned type classes (repeatedly and positively). What I mean is that I don't see why, in their presence, there's still a problem. On careful reread, I guess you don't see them as an example of "having various types extend a common interface"? (which would make them a solution, but excluded from the discussion) (edited to add - and I find that description to fit them just find, hence my confusion)
  - nrinaudo 11y ago
    That's exactly it: they're a good solution to the problem, but since type classes work specifically by avoiding subtype polymorphism (and are instead a mix of parametric and ad hoc polymorphism), they cannot be part of a discussion that is centered on whether or not subtype polymorphism is a good fit. But, yes. The more I code, the more it feels like type classes are never not a good answer.
    - dllthomas 11y ago
      The thing is, I don't see anything actually restricting the scope of discussion to subtype polymorphism. "The more I code, the more it feels like type classes are never not a good answer." As they are used in Haskell, they sometimes get awkward where you where multiple instances are relevant to the same data in the same scope. You can newtype cast around, but I've been wondering (with multiparameter typeclasses) if reifying the instance we care about is 1) useful, and 2) actually still distinct from explicitly passing the dictionary as a record. Regarding 1, I've consistently leaned "yes", although without tremendous confidence. Regarding 2, I've gone back and forth over time.