4 ms·

It's not dogma. This was my experience using Go. I haven't touched go in a while though. Did they fix the interface{} problem? Specifically, I ran into this

It's not dogma. This was my experience using Go. I haven't touched go in a while though. Did they fix the interface{} problem? Specifically, I ran into this when I was using a database library. Values that can be converted to a database-friendly format implement sql.Valuer. However, the library functions just took interface{} instead of sql.Valuer because primitive types could not implement sql.Valuer. Can they implement it now? Btw, you don't get a free pass at my other objections just because someone poked a hole in one of them. The other problems still stand. Take them one by one.

kjksf 10y ago
They can't for a very good reason. Let's say library A decides to add func (i int) MyMethod() and library B decides to add func (i int) MyMethod(). Then library C calls i.MyMethod(). Which MyMethod is executed? You can come up with an answer to that question (e.g. "pick random") but there is no sensible answer. To avoid this ambiguity you can only add methods to your own types but not someone else's (i.e. not to types defined in other packages or basic types).
weberc2 10y ago
There never was an interface problem. The sql libraries opt to accept an `interface{}` instead of `sql.Valuer` as a matter of convenience (so you don't have to define the requisite methods). It wasn't a technical limitation. > Btw, you don't get a free pass at my other objections just because someone poked a hole in one of them. The other problems still stand. Take them one by one. You didn't mention other problems, you just whined about Go's feature set. You didn't support your opinions with anything debatable, so there's nothing to discuss. > the language designers like to pretend it's not exception handling at all. > You have to name things starting with a capital letter to make them public. Who came up with this convention? It is not shared by any language ever. > There are built-in functions that use generics, but I'm not allowed to write one? Hypocrites.

kjksf 10y ago

They can't for a very good reason. Let's say library A decides to add func (i int) MyMethod() and library B decides to add func (i int) MyMethod(). Then library C calls i.MyMethod(). Which MyMethod is executed? You can come up with an answer to that question (e.g. "pick random") but there is no sensible answer. To avoid this ambiguity you can only add methods to your own types but not someone else's (i.e. not to types defined in other packages or basic types).

weberc2 10y ago

There never was an interface problem. The sql libraries opt to accept an `interface{}` instead of `sql.Valuer` as a matter of convenience (so you don't have to define the requisite methods). It wasn't a technical limitation. > Btw, you don't get a free pass at my other objections just because someone poked a hole in one of them. The other problems still stand. Take them one by one. You didn't mention other problems, you just whined about Go's feature set. You didn't support your opinions with anything debatable, so there's nothing to discuss. > the language designers like to pretend it's not exception handling at all. > You have to name things starting with a capital letter to make them public. Who came up with this convention? It is not shared by any language ever. > There are built-in functions that use generics, but I'm not allowed to write one? Hypocrites.