Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interface Upgrades in Go

avtok.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: Interface Upgrades in Go

#11

Post by thomasahle »

dcposch wrote: post #6

The zero-copy IO in Go is so elegant. I think you can really judge a language accurately by checking out its standard library. This is one of my favorite things about Go. By comparison, * The C++ STL. Fast and useful, but the implementation is nearly unreadable due to template soup. Here's one of the simpler parts! https://www.sgi.com/tech/stl/stl_vector.h * PHP. So bad it's basically a strawman. I'll include it beca…

For all the comments Go gets on its typesystem, I suppose

    	if rt, ok := dst.(ReaderFrom); ok {
    		return rt.ReadFrom(src)
    	}
Isn't the most terrible way anyone has seen pattern matching implemented.

At least it is better than Java's instanceof + cast.

Re: Interface Upgrades in Go

#12

Post by Laremere »

Goopplesoft wrote: post #7

Go's interfaces are great, but one of my annoyances is that you can't define an interface with values (methods only). Which makes little sense considering it works just fine with getters and setters. i.e: type Blah interface { Var string } wont work, but type Blah interface { GetVar() string } does. I'm sure theres a reason for this. Can someone shed some light?

An interface takes any value for which the required methods are defined on it.

Methods can be defined on any type declared in the package.

A type in go can be a lot more that just a struct; it can be any type in the language. So while it may make sense to have values on interfaces for structs, values don't make any sense for functions, pointers, interfaces, or extensions to built in types.

Re: Interface Upgrades in Go

#14

Post by kjksf »

Goopplesoft wrote: post #7

Go's interfaces are great, but one of my annoyances is that you can't define an interface with values (methods only). Which makes little sense considering it works just fine with getters and setters. i.e: type Blah interface { Var string } wont work, but type Blah interface { GetVar() string } does. I'm sure theres a reason for this. Can someone shed some light?

The purpose of the interface is to abstract how something is done.

In your example, GetVar() can be implemented in a number of ways. Returning Var field of Blah struct is only one such way (and if there was only one implementation, there would be no need for an interface).

In that light, adding variables as part of interface doesn't make sense. Variables are fixing the thing that interface is meant to make flexible.

In Go, you can achieve re-using of a bunch of variables (and their methods) by embedding - put the variables you want to re-use into a separate struct and embed that struct in other structs. See https://golang.org/doc/effective_go.html#embedding

Re: Interface Upgrades in Go

#15

Post by Goopplesoft »

kjksf wrote: post #14
Goopplesoft wrote: post #7

Go's interfaces are great, but one of my annoyances is that you can't define an interface with values (methods only). Which makes little sense considering it works just fine with getters and setters. i.e: type Blah interface { Var string } wont work, but type Blah interface { GetVar() string } does. I'm sure theres a reason for this. Can someone shed some light?

The purpose of the interface is to abstract how something is done. In your example, GetVar() can be implemented in a number of ways. Returning Var field of Blah struct is only one such way (and if there was only one implementation, there would be no need for an interface). In that light, adding variables as part of interface doesn't make sense. Variables are fixing the thing that interface is meant to make flexible.…

It seemed to me that interfaces have a second function of providing partial uniformity across types (not just abstracting procedures). I.e the Animal interface has a method `Speak() string` and you have a function that takes an Animal that prints something like "Animal type {species} says {speak}" you would have to define a getter on the Animal's species even though its not a really a procedure. But I see what you mean though. Thanks!

Re: Interface Upgrades in Go

#16

Post by skybrian »

I'm wondering what programmers in functional programmers do about this sort of thing? It seems like they have much stronger type constrants; subclassing and upcasting just plain don't work. And if they did work, it would invalidate the sort of proofs that functional programmers like to do.

Re: Interface Upgrades in Go

#17

Post by skybrian »

thomasahle wrote: post #11
dcposch wrote: post #6

The zero-copy IO in Go is so elegant. I think you can really judge a language accurately by checking out its standard library. This is one of my favorite things about Go. By comparison, * The C++ STL. Fast and useful, but the implementation is nearly unreadable due to template soup. Here's one of the simpler parts! https://www.sgi.com/tech/stl/stl_vector.h * PHP. So bad it's basically a strawman. I'll include it beca…

For all the comments Go gets on its typesystem, I suppose if rt, ok := dst.(ReaderFrom); ok { return rt.ReadFrom(src) } Isn't the most terrible way anyone has seen pattern matching implemented. At least it is better than Java's instanceof + cast.

It certainly looks weird at first, but is there anything objectively wrong with it?

Re: Interface Upgrades in Go

#18

Post by zaphar »

thomasahle wrote: post #11
dcposch wrote: post #6

The zero-copy IO in Go is so elegant. I think you can really judge a language accurately by checking out its standard library. This is one of my favorite things about Go. By comparison, * The C++ STL. Fast and useful, but the implementation is nearly unreadable due to template soup. Here's one of the simpler parts! https://www.sgi.com/tech/stl/stl_vector.h * PHP. So bad it's basically a strawman. I'll include it beca…

For all the comments Go gets on its typesystem, I suppose if rt, ok := dst.(ReaderFrom); ok { return rt.ReadFrom(src) } Isn't the most terrible way anyone has seen pattern matching implemented. At least it is better than Java's instanceof + cast.

For even more similar look to pattern matching look at Go's type switch.

    switch i.(type) {
        case OptionalInterface1:
           // do some extra thing we allow
        case OptionalInterface2:
           // do some other extra thing we allow
    }
It's really good when you have a set of mutually exclusive interfaces or types.
Post reply on HN