> So yes: Using a type alias has advantages, but no, this advantage is
never realized because neither the alias nor the plain type decl are used
in practice.
The ResonseWriter is a bad example because it has a method `Header()
http.Header`, for which you must import net/http regardless.
Take fmt.Stringer, `type Stringer interface { String() string }`. I could
perfectly well define `type MyStringer interface { String() string }` and
use that instead of fmt.Stringer (if fmt.Stringer were an alias, with much
more flexibility), and avoid importing fmt altogether. And even this
scenario is trivial (I have nothing agaist importing fmt!), but for my own
interfaces having the interface defined in separate places can help avoid
import cycles, make packages more locally contained, keep compilation
faster, etc.
Hence why I'm asking for reasons against it. I have used this before and it
has served me well, so I know there are advantages.
On Tuesday, September 8, 2020 at 11:41:25 AM UTC+2 Volker Dobler wrote:
> In practice you never declare the same interface twice
> switch from one to the other. Why would anybody declare
> his own ResonseWriter interface if net/http.ResponseWriter
> exists?
>
> So yes: Using a type alias has advantages, but no, this
> advantage is never realized because neither the alias nor
> the plain type decl are used in practice.
>
> V.
>
> On Tuesday, 8 September 2020 at 10:13:23 UTC+2 Javier Zunzunegui wrote:
>
>> TLDR: Why should I NOT the alias form `type ... = interface {...}`
>> instead of the standard `type ... interface {...}` for interface
>> declarations?
>>
>> The extended question:
>>
>> The normal type definition for an interface in go would be `type TypeName
>> interface {...}`. This results in a new type, which is assignable to other
>> types of the similar interfacce, such that this is valid:
>> ```
>> type I1 interface{ Foo() }
>> type I2 interface{ Foo() }
>> var _ I1 = I2(nil)
>> ```
>> But these are different types, such that any function with one of these
>> in the signature can't be converted to a similar function with the other,
>> such that this is NOT valid:
>> ```
>> var _ func(I1) = (func(I2))(nil)
>> ```
>>
>> Declare the types as aliases <https://yourbasic.org/golang/type-alias/>
>> however,
>> and the limitation dissapears:
>> ```
>> type I1 interface{ Foo() }
>> type I2 interface{ Foo() }
>> var _ I1 = I2(nil) // still valid
>> var _ func(I1) = (func(I2))(nil) // now valid
>> ```
>>
>> A runnable example of the below using `http.ResponseWriter`:
>>
>> - without alias <https://play.golang.org/p/dKdh80LNMt0>
>> - with alias <https://play.golang.org/p/sR5hB0ParA0>
>>
>> My point being using aliases offers an advantage (more flexible
>> assignment and interface implementation) and to my knowledge no meaningful
>> drawback. So why not use it everywhere?
>>
>
--
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/8580a406-f24b-4475-819d-1a4e08ed5e38n%40googlegroups.com.
