to work has nothing to do with generics; methods are always "removed" from types defined this way. If you want you can cast `t` to a `*container[fish]` and call it, but this is also where I would ask why "extend" rather than compose - are you gaining anything by ensuring identical layouts?
Re. "temporary restriction": Although there's agreement something should improve around `comparable`, there's no concrete design approved to solve it. It may persist for many versions, or indefinitely.
(Vs. e.g re-enabling better type inference where the goal is known and it's "just" implementation work.)
There will be some permanent restrictions in Go custom design, but I think the `comparalbe` one is not one of them. My personal prediction is it will be solved before Go 1.21.
Go doesn’t have inheritance. Defining one type in terms of another is not a subclass. It has embedding, which is a close substitute based on composition, but it isn’t the same.
It’s a little confusing because for primitive operations, it kind of looks like Go has inheritance, but this isn’t true for user-defined methods. (And automatic casting might in some cases compound the confusion.)
> automatic casting might in some cases compound the confusion.
This is why you should always be careful to distinguish conversions (which aren't automatic) from assignment of untyped constants/literals (which does automatically attach the type, but isn't casting).
data T1 = T1 Int
m :: T1 -> ()
m t = ()
newtype T2 = T2 T1
main :: IO ()
main =
let t2 = T2 (T1 23)
v = m t2
in return ()
Gets:
main.hs:11:15: error:
\* Couldn't match expected type `T1' with actual type `T2'
\* In the first argument of `m', namely `t2'
In the expression: m t2
In an equation for `v': v = m t2
|
11 | v = m t2
| ^^
> But why (1)? If a `fishTank` is a `container[fish]`
But a `fishTank` is not a `container[fish]`.
In common parlance
type T Thing
is newtyping. T has the same implementation as the underlying type, and Go allows conversions back and forth, but they are otherwise unrelated, and the new type does not share the interface (method set) of the original.
Oh I misunderstood `type T Thing` to be an alias and not a haskell-style newtype.
$ ghci
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Prelude> class HasField a where { field1 :: a -> Int }
Prelude> data Foo = Foo
Prelude> instance HasField Foo where { field1 f = 2 }
Prelude> field1 Foo
2
Prelude> newtype Bar = Bar Foo
Prelude> :t Bar
Bar :: Foo -> Bar
Prelude> field1 (Bar Foo)
<interactive>:7:1: error:
• No instance for (HasField Bar) arising from a use of
‘field1’
• In the expression: field1 (Bar Foo)
In an equation for ‘it’: it = field1 (Bar Foo)
Prelude> type Baz = Foo
Prelude> field1 (Foo :: Baz)
2
When people say Go is not an OO language, this is what they mean. Concrete type declarations define storage, not is-a hierarchies. A fishTank is not a container[fish], any more or less than it is any other `{ string, []fish }`.
And yet OO-isms are replete throughout implementations in go. `interface{}` all the things is another of the worst things about go. It practically begs for engineers to engage in all the worst practices of OO-ism and unit test zealotry.
interface{} isn’t pervasive in Go, it doesn’t tend to get abused often in practice, it has nothing to do with OO at all, and it doesn’t lead to any particular ideology about unit testing. It seems like you are mistaken on all counts.
1) The failure of
to work has nothing to do with generics; methods are always "removed" from types defined this way. If you want you can cast `t` to a `*container[fish]` and call it, but this is also where I would ask why "extend" rather than compose - are you gaining anything by ensuring identical layouts?2) The bigger issue, that interfaces cannot require their implementations to be comparable, is https://github.com/golang/go/issues/52614 and linked tickets.