On Thu, Oct 19, 2023 at 6:18 PM Nurahmadie Nurahmadie
<nurahma...@gmail.com> wrote:
>
> There are two ways to enable this, which are worth discussing further as of
> why Go decided to behave this way.
>
> To use type alias as mentioned before `type MatrixF64 = Matrix[float64]`,
> this is generally works but unfortunately, doesn't worth it in the case of
> aliasing primitives type, i.e. `type String = string` won't allow you to bind
> new methods to `String` unlike `type String string`. I would like to know why.
> To use type embedding such as: type MatrixF64 struct { Matrix[float64] },
> since struct/interface embedding will allow the parent struct to call
> embedded methods/fields directly.
>
>
> Again, I would love to see the motivation between these design decisions,
> pretty much I would like to allow new methods to be attached to type
> primitives without resorting to manual type casting / type assertion, but
> that's another topic.
Adding methods to a primitive type, or more generally adding methods
to a type defined in a different package, would cause different
packages to behave differently depending on whether they see the
methods. That would be confusing. It would meant that type
assertions would sometimes succeed and sometimes fail, depending on
the exact sequence of function calls used.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUeKTpAzjOt3hyJpOfxbXQrB891c1BrG9zYKgaPOFU8xQ%40mail.gmail.com.
