71–80 of 115 posts
Thats whats in my mind.. and fix the the documentation so the classes interlink and it a bit of a java/md/rst/doc style..
Go developer here. I posted this on the blog too. """ This is a mistake, plain and simple. It was pointed out on the Go developer mailing list a few days before your post, and you can see my reply there. NewRequest should take an io.ReadCloser. Unfortunately, due to backwards compatibility, a long standing semantic mistake like this is not something we can just fix, but we've at least documented it. The tweet you quo…
I remember writing extension methods in C# for IEnumerable, which would of course take in an IEnumerable, but saw if the actual input was a ICollection, IList etc to optimize the operations.
Supporting 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 mad…
> There are a few languages out there that don't support typecasting. I think SML was one, for example. Haskell too, unless you explicitly opt in with Data.Typeable. It's arguably true in a certainly commonly-used subset of C++ as well: this type of typecast doesn't work in C++ unless you use dynamic_cast or another RTTI system (like COM). dynamic_cast only works on classes with a vtable. Many C++ projects don't use…
for those not familiar with Go, here's the problem translated in C terms: "I passed a pointer to your function and it called free() on it. how dare you!"
More "I passed a pointer to your function and it called free() on it, without documenting that it was taking ownership of the memory ". Ownership contracts are an important part of the API of any function that does stuff with resources, whether memory, file descriptions, network connections, etc. If the API implies that it takes a pointer to a resource but will only read from or write to it, and then disposes of it,…
Here is another case where weak- and dynamic-typing language features have come up in the context of resource management.
I'm not saying this one example proves anything, just that it might be interesting to be on the lookout for other events of this pattern.
Go developer here. I posted this on the blog too. """ This is a mistake, plain and simple. It was pointed out on the Go developer mailing list a few days before your post, and you can see my reply there. NewRequest should take an io.ReadCloser. Unfortunately, due to backwards compatibility, a long standing semantic mistake like this is not something we can just fix, but we've at least documented it. The tweet you quo…
I know of atleast one instance in C# where something like this happens. The IEnumberable .Count() extension sees if the input is actually a ICollection and uses the count on that to get the count directly, rather than iterating over it. I remember writing extension methods in C# for IEnumerable , which would of course take in an IEnumerable , but saw if the actual input was a ICollection , IList etc to optimize the o…
Go developer here. I posted this on the blog too. """ This is a mistake, plain and simple. It was pointed out on the Go developer mailing list a few days before your post, and you can see my reply there. NewRequest should take an io.ReadCloser. Unfortunately, due to backwards compatibility, a long standing semantic mistake like this is not something we can just fix, but we've at least documented it. The tweet you quo…
Earlier quoted context omitted.
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.
It's just not tenable, and we know this from experience (before Go 1 we introduced breaking changes with each stable release).
FWIW, this is the first time we've encountered this bug, and it's been part of Go since it was released. Hardly worth breaking people's code for.
Earlier quoted context omitted.
I know of atleast one instance in C# where something like this happens. The IEnumberable .Count() extension sees if the input is actually a ICollection and uses the count on that to get the count directly, rather than iterating over it. I remember writing extension methods in C# for IEnumerable , which would of course take in an IEnumerable , but saw if the actual input was a ICollection , IList etc to optimize the o…
I'm not a heavy C# dev, but I don't understand why your first paragraph would be so: isn't that the point of implementing an interface like IEnumerable -- so that you can implement Count() in an optimized, specialized way that "gets the count directly"?
Earlier quoted context omitted.
I know of atleast one instance in C# where something like this happens. The IEnumberable .Count() extension sees if the input is actually a ICollection and uses the count on that to get the count directly, rather than iterating over it. I remember writing extension methods in C# for IEnumerable , which would of course take in an IEnumerable , but saw if the actual input was a ICollection , IList etc to optimize the o…
I'm not a heavy C# dev, but I don't understand why your first paragraph would be so: isn't that the point of implementing an interface like IEnumerable -- so that you can implement Count() in an optimized, specialized way that "gets the count directly"?
If you wanted to implement your own "Count" you would implement ICollection which the IEnumerable extension method would call into.