On 2013/05/14 22:21:56, bradfitz wrote:
I would rather not see a proliferation of GobEncode and GobDecode
functions all
over the standard library.
I would rather not see a proliferation of GobEncode and GobDecode
functions all
over the standard library.
if they have a password set (to differentiate no password from an empty
password), so there's no way to for encoding/<whatever> to handle them
directly. Maybe we should remove that private field rather than
explicitly implementing encoding/decoding?
It gives me Java Serializable flashbacks.
Can't these be registered with gob somehow instead?
Can't these be registered with gob somehow instead?
https://codereview.appspot.com/8325045/diff/5001/src/pkg/net/url/url.go
File src/pkg/net/url/url.go (right):
https://codereview.appspot.com/8325045/diff/5001/src/pkg/net/url/url.go#newcode298
src/pkg/net/url/url.go:298: if _, err :=
buf.Write([]byte(u.username)); err !=
nil {
WriteString, not Write. here and elsewhere.
Noted, will update those.buf.Write([]byte(u.username)); err !=
nil {
WriteString, not Write. here and elsewhere.
Regards,
Alberto
https://codereview.appspot.com/8325045/
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.