Go didn't fail you, OOP failed you.
Stunned by Go
41–50 of 115 posts
Re: Stunned by Go
#42Wow, this is pretty unfortunate. Also a very good example of why so many people maintain that Go is not nearly as statically typed as languages like Haskell or OCaml: casting (essentially subverting the type system) is very common, and limits most of the type system's advantages. In large part this is because Go's type system is not very expressive. I would just like to point out that OCaml did the same things as Go…
Thanks for the informative comment. > So it would automatically realize that the function called the close method, and infer the appropriate type. So, if i understand this correctly, OCaml would infer that the function takes "an object with write() and close() methods" because it uses both methods in its definition. That's reasonable. But wouldn't that prevent it from accepting objects that don't have a close() metho…
You're right; OCaml would have to supply two different functions, one that takes an object that exposes (); .. > and another that takes (); .. >. Reproducing the Go system would require the ability to, at runtime, see whether an object of type (); .. > can be downcasted to (); .. >, which would require more runtime type information than OCaml currently supplies. Some people have made proposals to implement such downcasting (throwing an exception if the downcast fails), which would permit the Go-like implementation, but as far as I know, such proposals haven't been met with much enthusiasm.
Re: Stunned by Go
#43Earlier quoted context omitted.
In Go, a type doesn't have to declare that it implements an interface; it automatically satisfies an interface if it implements the appropriate methods. Most interfaces in Go only contain one method. If a type has a Close() method, then it is a Closer. The code that tries to cast it to a Closer will succeed. So to answer your question, it doesn't matter what the semantics of your Close() method are, it will succeed s…
> your type has a method with that name. I would say with the same function signature, not just the name.
Go doesn't support overloading. Method dispatch is done by name only.
Re: Stunned by Go
#44Go didn't fail you, OOP failed you.
There's nothing about OOP that requires weak typing.
Re: Stunned by Go
#45I feel like the author missed a great opportunity. "Stopped by Go"
Stop, Go
Re: Stunned by Go
#46Earlier quoted context omitted.
> your type has a method with that name. I would say with the same function signature, not just the name.
Go doesn't support overloading. Method dispatch is done by name only. http://golang.org/doc/faq#overloading
It doesn't work :)
http://play.golang.org/p/PVS5sarmHb
Re: Stunned by Go
#47Earlier quoted context omitted.
Thanks for the informative comment. > So it would automatically realize that the function called the close method, and infer the appropriate type. So, if i understand this correctly, OCaml would infer that the function takes "an object with write() and close() methods" because it uses both methods in its definition. That's reasonable. But wouldn't that prevent it from accepting objects that don't have a close() metho…
You're right; OCaml would have to supply two different functions, one that takes an object that exposes (); .. > and another that takes (); .. > . Reproducing the Go system would require the ability to, at runtime, see whether an object of type (); .. > can be downcasted to (); .. > , which would require more runtime type information than OCaml currently supplies. Some people have made proposals to implement such dow…
Thanks for the examples of record types in OCaml.
> but as far as I know, such proposals haven't been met with much enthusiasm.
Well, if the proposed use cases are similar to this http Go library, then i think i can see why that's the case. As just adding a close: () method to a type could mean that code that uses that type now behaves differently.
Re: Stunned by Go
#48Earlier quoted context omitted.
> your type has a method with that name. I would say with the same function signature, not just the name.
Go doesn't support overloading. Method dispatch is done by name only. http://golang.org/doc/faq#overloading
But interface satisfaction is by signature, not name, and that is what is being discussed, not method dispatch.
Re: Stunned by Go
#49Supporting typecasting is hardly earth-shattering. Pretty much every statically typed programming language in actual use supports typecasts. That includes Scala, Java, C++, C, C#, Pascal, Algol, and even Ada.
This title should be "stunned by shitty poorly documented library function" not "stunned by Go."
There are a few languages out there that don't support typecasting. I think SML was one, for example. But they made a lot of other design choices to be able to support that choice, and so far that set of choices has not gained popularity. At minimum, you would need a fairly complex type system with generics to be able to completely forbid typecasting. You also run into problems where stable APIs completely block progress in a particular area.
Re: Stunned by Go
#50Earlier quoted context omitted.
I was just criticizing the publishing skills of some people... The problem itself is unfortunate and I am personally not a huge fan of the "no API changes" philosophy participated by the Go team. I can understand the reasons behind it, but it's still hard to read several CLs per day that are abandoned or done differently (in a non-optimal way) because of this contract.
It's much better for the core team to compromise a little than force everyone to update their code all the time. In particular, small semantic changes that can't be caught statically will just break people's code with no warning whatsoever. That's bad.
The end user gets to decide when they upgrade the toolchain so it wouldn't be "no warning" if they wrote about the change in the release notes. I'd much rather they break code relying on undocumented weird behavior, than document the weird behavior and keep it alive indefinitely.