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

Stunned by Go

how-bazaar.blogspot.co.nz

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Stunned by Go

#91

Post by mseepgood »

Locke1689 wrote: post #87
manojlds wrote: post #72

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…

This is not the same thing. The problem with the Go implementation is essentially that the method is semantically different from the expected method. Closing a stream is semantically different from not closing a stream. It just is. The Go method was just wrong . The problem was not the type introspection. There's nothing wrong with us attempting to do optimization for ICollection`1 or the rest of the collection inter…

> This is not the same thing. The problem with the Go implementation is essentially that the method is semantically different from the expected method.

No-one is arguing about the Close() case. However, the io.Copy() case is comparable to the IEnumerable.Count() implementation.

Re: Stunned by Go

#93

Post by [deleted] »

stiff wrote: post #86
rsc wrote: post #65

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…

You adopted "looking for custom methods" without making it part of the contract in any way as a best practice in the standard library, but it is a "mistake, plain and simple"? Doesn't it, like, illustrate a serious language and/or standard library design issue? What can possibly motivate breaking encapsulation in the standard library? Why even have interfaces if even the standard library will abuse them? Your respons…

[deleted]

Re: Stunned by Go

#94

Post by nly »

marshray wrote: post #69
nly wrote: post #63

Earlier quoted context omitted.

dynamic_cast downcasts in C++ only work across public inheritance. In particular a object that inheritance a Closable interface privately and a Reader interface publicly wouldn't allow a cross cast. dynamic_cast isn't a loophole in the type system, it's there to strengthen it.

I don't think I've ever seen C++ that inherited an interface privately. That said, it's extremely common for classes to lack any virtual functions and thus be unusable with dynamic_cast.

Well protected is the default.

Re: Stunned by Go

#95

Post by pjmlp »

nly wrote: post #94
marshray wrote: post #69

Earlier quoted context omitted.

I don't think I've ever seen C++ that inherited an interface privately. That said, it's extremely common for classes to lack any virtual functions and thus be unusable with dynamic_cast.

Well protected is the default.

The default is private for classes and public for structs.

Section 11.2 of the C++ standard.

Re: Stunned by Go

#96

Post by pjmlp »

marshray wrote: post #69
nly wrote: post #63

Earlier quoted context omitted.

dynamic_cast downcasts in C++ only work across public inheritance. In particular a object that inheritance a Closable interface privately and a Reader interface publicly wouldn't allow a cross cast. dynamic_cast isn't a loophole in the type system, it's there to strengthen it.

I don't think I've ever seen C++ that inherited an interface privately. That said, it's extremely common for classes to lack any virtual functions and thus be unusable with dynamic_cast.

By default it is private.

Usually private inheritance is mostly used for library code, as a way for code reuse but without exposing the inheritance relationship to the class users. Also coupled with mixins sometimes.

Re: Stunned by Go

#97

Post by jefffoster »

Locke1689 wrote: post #88
stiff wrote: post #86

Earlier quoted context omitted.

You adopted "looking for custom methods" without making it part of the contract in any way as a best practice in the standard library, but it is a "mistake, plain and simple"? Doesn't it, like, illustrate a serious language and/or standard library design issue? What can possibly motivate breaking encapsulation in the standard library? Why even have interfaces if even the standard library will abuse them? Your respons…

Theoretically, if the standard library only optimizes about interfaces whose semantics are in the standard library (i.e., standard library interfaces) that's perfectly fine. What worries me about this approach is that Go is essentially duck-typed -- implementing an interface isn't necessary for something to appear like it implements an interface, and a method signature doesn't implicitly carry its semantic informatio…

Something like the proposal for C++ Concepts captures some of the semantics via axioms (http://en.wikipedia.org/wiki/Concepts_(C%2B%2B)#Axioms) seems like a really interesting solution for this idea.

Re: Stunned by Go

#98

Post by lmm »

manojlds wrote: post #72
rsc wrote: post #65

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…

That's morally wrong, but at least the language provides an alternative: you could provide overloads for the function, and so it would be clear that the Count() on an ICollection was a different method from the Count() on an IEnumerable (at least, I assume you can - if C# extension methods make overloading impossible then this is a Bad Thing and should be fixed. (But even then, a problem with extension methods is much less significant than a problem with all functions)). In Java we see this with e.g. Guava's ImmutableList.copyOf(...), which has several overloads taking different subinterfaces (iterable, collection, list, ...) so you can reasonably tell that the method will use all the details of its input.

Re: Stunned by Go

#99

Post by rsc »

marshray wrote: post #68
rsc wrote: post #65

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…

Out of simple idle language-design-bystander curiosity, can you recall any other times where this class of bug has bitten?

No.

A related bug would be if you implement Read and (say) ReadByte, but your ReadByte is buggy. Then when you get weird behavior passing yourself to something that expects a Reader (but internally needs byte-at-a-time and uses ReadByte to avoid double-buffering the input) it can take a minute or two to realize that ReadByte might be the problem and not Read. I've only seen that once or twice.

Re: Stunned by Go

#100

Post by dragonwriter »

pedromorgan wrote: post #71

Why dont the Go team do golang2 now.. There are a few issues.. already mentioned in open fire chat this year 2013.. Would be nicer to actually recongise flaws now.. and offer alternative.. even faster tht python 3000 could ? 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..

> Why dont the Go team do golang2 now.. There are a few issues..

I suspect that it is because Go 1 (issues and all) is useful enough that people are making productive use of it, and they'd like to flush out more of the issues that may exist -- and give more time for different approaches to those issues to be tried in experimental forks and, where possible, libraries, preprocessers, etc.

> and fix the the documentation so the classes interlink

Not sure what this means, and Go doesn't have classes. (Its not just an issue of calling classes different names, it divides up functionality differently than class-based OO systems -- packages are in a sense like classes [they are the closest equivalent to the function of classes as containers of static methods], structs are a bit like classes [in the role of containing members, and in that anonymous embedding approximates inheritance], every type is a bit like classes [in that any type can have methods attached to it, so long as they are attached in the same package as the type is defined]; but all these things are also unlike classes in various ways, too.)

Post reply on HN