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

Go Data Structures (2009)

research.swtch.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Go Data Structures (2009)

#11

Post by krakensden »

codeflo wrote: post #10

I wish there were a way to create custom data structures without casting to and from interface{} all the time. Heck, it would already help if there were a shorthand for interface{}, like "any" or something.

The usual pattern is to use a type that requires the thing you pass in to have methods that you use for the data structure, like sort.Interface[1]. It's faster, safer, and better than using interface{}.

As for shorthand, behold!

    type any interface{}
[1]: http://golang.org/pkg/sort/#Interface

Re: Go Data Structures (2009)

#12

Post by mitchty »

krakensden wrote: post #9
aaronblohowiak wrote: post #6

Earlier quoted context omitted.

for historical note, this change was made in may 2012 Java 7u6

That's kind of a big deal for a point release...

There is a good reason for it however. http://www.javaadvent.com/2012/12/changes-to-stringsubstring...

Re: Go Data Structures (2009)

#13

Post by oofabz »

grannyg00se wrote: post #8

make(* Point) seems much better than having a separate new keyword. Surprised to hear that was changed after just a few days.

The "new" keyword is practically unused in modern Go development, but is kept for backwards compatibility. The usual way to make a point is "p := &Point{}", without using any keyword.

Re: Go Data Structures (2009)

#14

Post by codeflo »

krakensden wrote: post #11
codeflo wrote: post #10

I wish there were a way to create custom data structures without casting to and from interface{} all the time. Heck, it would already help if there were a shorthand for interface{}, like "any" or something.

The usual pattern is to use a type that requires the thing you pass in to have methods that you use for the data structure, like sort.Interface[1]. It's faster, safer, and better than using interface{}. As for shorthand, behold! type any interface{} [1]: http://golang.org/pkg/sort/#Interface

That introduces a new named type though, i.e., the "any" in your package is different from the "any" in mine, which is not what I want.

(Unless I'm mistaken here, which might very well be the case.)

Re: Go Data Structures (2009)

#15

Post by enneff »

codezero wrote: post #4
iand wrote: post #2

Note that this is from 2009. Although the main details have not changed, the int type is more commonly 64 bits now (since 64 bit architectures are much more common)

Do you know what version that happens in? I tested on my 32 and 64 bit platforms with golang 1.1 and a static definition of an integer results in type int (which is explicitly 32 bit) package main import "fmt" import "reflect" func main() { i := 3 z := reflect.ValueOf(i) fmt.Printf("%s\n", z.Kind()) } // $./test // int // $ It's my understanding that this intentional and won't change, only explicit declarations of in…

The size of int on 64-bit systems was increased to 64 bits as of Go 1.1: http://golang.org/doc/go1.1#int

Re: Go Data Structures (2009)

#16

Post by enneff »

mitchty wrote: post #12
krakensden wrote: post #9

Earlier quoted context omitted.

That's kind of a big deal for a point release...

There is a good reason for it however. http://www.javaadvent.com/2012/12/changes-to-stringsubstring...

Still, it is a change that could dramatically affect the behavior of some programs. A program that takes many references to one string might consume a lot of memory when those references become copies.

Re: Go Data Structures (2009)

#17

Post by krakensden »

codeflo wrote: post #14
krakensden wrote: post #11

Earlier quoted context omitted.

The usual pattern is to use a type that requires the thing you pass in to have methods that you use for the data structure, like sort.Interface[1]. It's faster, safer, and better than using interface{}. As for shorthand, behold! type any interface{} [1]: http://golang.org/pkg/sort/#Interface

That introduces a new named type though, i.e., the "any" in your package is different from the "any" in mine, which is not what I want. (Unless I'm mistaken here, which might very well be the case.)

Check it out: http://play.golang.org/p/l9yn0PRbrd

Anyway, that's the point of go's type inference- if the object implements the necessary parts of the interface, it counts as that kind of object.

Re: Go Data Structures (2009)

#18

Post by codezero »

enneff wrote: post #15
codezero wrote: post #4

Earlier quoted context omitted.

Do you know what version that happens in? I tested on my 32 and 64 bit platforms with golang 1.1 and a static definition of an integer results in type int (which is explicitly 32 bit) package main import "fmt" import "reflect" func main() { i := 3 z := reflect.ValueOf(i) fmt.Printf("%s\n", z.Kind()) } // $./test // int // $ It's my understanding that this intentional and won't change, only explicit declarations of in…

The size of int on 64-bit systems was increased to 64 bits as of Go 1.1: http://golang.org/doc/go1.1#int

Cool, thanks for the clarification, this makes sense!

Re: Go Data Structures (2009)

#19

Post by codezero »

iand wrote: post #7
codezero wrote: post #4

Earlier quoted context omitted.

Do you know what version that happens in? I tested on my 32 and 64 bit platforms with golang 1.1 and a static definition of an integer results in type int (which is explicitly 32 bit) package main import "fmt" import "reflect" func main() { i := 3 z := reflect.ValueOf(i) fmt.Printf("%s\n", z.Kind()) } // $./test // int // $ It's my understanding that this intentional and won't change, only explicit declarations of in…

i := 3 means declare i to be an "int", which is the default numeric type. The size of that int will vary from platform to platform. See http://golang.org/ref/spec#Numeric_types

Awesome, thanks!

Re: Go Data Structures (2009)

#20

Post by rsc »

oofabz wrote: post #13
grannyg00se wrote: post #8

make(* Point) seems much better than having a separate new keyword. Surprised to hear that was changed after just a few days.

The "new" keyword is practically unused in modern Go development, but is kept for backwards compatibility. The usual way to make a point is "p := &Point{}", without using any keyword.

Not true. I count "new" being used about half as often as "&Point{}" in the Go standard library. That's not "practically unused".

  g% cg -c -f 'g/go/src/pkg.*\.go' '\bnew\(' | total 2
  1485
  g% cg -c -f 'g/go/src/pkg.*\.go' '\&[A-Za-z0-9_.]+\{' | total 2
  3051
  g% cg -c -f 'g/go/src/pkg.*\.go' . | total 2
  430482
  g%
So 430,482 non-blank lines of code, 1485 lines with new, 3051 lines that look like a struct pointer literal.
Post reply on HN