Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I don't understand this comparison. The C idiom you mention is concretely typed (i.e. C doesn't have interfaces, so it doesn't have dynamic types), so I fail to see what it has to do with interfaces. And it makes *far* more sense to check if you got passed a nil-pointer, than to check the concrete

Re: [go-nuts] Extending an existing type by embedding

Bingo! Thanks a lot for your *clear explanation* Jason! I went with your first choice and it works perfectly. Now wish somebody can answer the second part -- extend it even further for two different `VisitToken()` behaviors... On Mon, Jan 1, 2018 at 11:39 PM, Jason Phillips

Re: [go-nuts] Extending an existing type by embedding

html.NewTokenizer returns a pointer to a Tokenizer. So, you probably want to embed a pointer: type MyTokenizer struct { *html.Tokenizer } func NewMyTokenizer(i io.Reader) *MyTokenizer { z := html.NewTokenizer(i) return {z} } If for some reason your want/need the Tokenizer value, you'll

Re: [go-nuts] Extending an existing type by embedding

On Mon, Jan 1, 2018 at 10:21 PM, Ian Lance Taylor wrote: > On Mon, Jan 1, 2018 at 6:46 PM, Tong Sun wrote: > > > > I think I generally understand how embedding > > (https://golang.org/doc/effective_go.html#embedding) works in GO. > > However, when it comes

Re: [go-nuts] Extending an existing type by embedding

On Mon, Jan 1, 2018 at 6:46 PM, Tong Sun wrote: > > I think I generally understand how embedding > (https://golang.org/doc/effective_go.html#embedding) works in GO. > However, when it comes to the following problem, I'm at lost again. > > I'm trying to extend the

[go-nuts] Extending an existing type by embedding

Hi, I think I generally understand how embedding (https://golang.org/doc/effective_go.html#embedding) works in GO. However, when it comes to the following problem, I'm at lost again. I'm trying to extend the `html.Tokenizer` with new methods of my own: type MyTokenizer struct {

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Drifting back toward the original subject, I'm reminded of the non-bsd-c idiom of char *foo(char *p) { if (p != NULL && *p != NULL) { return some string operation... } ... It seems logical to check the type of the contents of an interface type, and its presence in a function

Re: [go-nuts] Fuzzy behaviour of go test with examples in sort package

On Mon, Jan 1, 2018 at 8:37 PM Kshitij Saraogi wrote: > While running the test suite in the "sort" pacakge, I found that all the examples are not being evaluated. > I tried running `$ go test -v src/sort` from the base directory of the repository. > > The tests such as

[go-nuts] Fuzzy behaviour of go test with examples in sort package

While running the test suite in the "sort" pacakge, I found that all the examples are not being evaluated. I tried running `$ go test -v src/sort` from the base directory of the repository. The tests such as `ExampleIntsAreSorted`, `ExampleFloat64s` are not run unless explicitly instructed to.

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Since an interface can be nil I’ve been assuming interface behaves like slice with a pointer to the concrete data within a reference struct (that also includes the data type) which is passed around as an interface var. This playground shows that the interface var is a similar reference type to