3 ms·

Regarding #6, starting with 1 is better than starting with 0, but even better is using negative values: http://play.golang.org/p/ES8nNv4PeW http://play.golang.o

by 4ad 11y ago

Regarding #6, starting with 1 is better than starting with 0, but even better is using negative values: http://play.golang.org/p/ES8nNv4PeW http://play.golang.org/p/ES8nNv4PeW Also regarding #6, the author didn't say it, but with iota is really trivial to create power of two constants, so you can combine them: http://play.golang.org/p/rzD3Vl0C4q http://play.golang.org/p/rzD3Vl0C4q For #5, he should have mentioned the stringer tool to maintain the list of strings for you: https://godoc.org/golang.org/x/tools/cmd/stringer https://godoc.org/golang.org/x/tools/cmd/stringer #10 really depends. There are many cases where you want to wrap your map, but there are many other cases (more cases dare I say), where it doesn't really matter because you only use the map (which is embedded in s struct) in very few places (basically some methods of that struct). The example also fails to synchronise reads. A more important case that is not mentioned is that if you often initialise once and read many times, without ever writing again, you don't need that kind of wrapper in those scenarios. And you also don't want that kind of wrapper even if you read and write often, but read more than one value at a time. That hurts performance, but can even limit your available semantics. With an explicit lock you can arrange so that your map presents a consistent snapshot at all times.

sambeau 11y ago
> but even better is using negative values Honest question: Why?
- 4ad 11y ago
  Most small values in programs are positive (lengths, counts, etc), so it's possible to write a value to something that should be initialised to a constant by mistake, and you'll never know, since the ranges overlap. But if you use negative values, and you write a positive value, when you see it, you'll know. Of course this is a very trivial thing, but it helped me many times. Sometimes it's better to use typed constants with a custom type, then the Go type system will help you and not let you assign things of a different type. Note that I only said sometimes, in many cases it's better to use untyped constants (or use primitive types rather than custom integers), and positive integers because you can calculate the constant corresponds to some value from a delta, or from some other criteria, like here: https://github.com/golang/go/blob/54789eff385780c54254f822e09505b6222918e2/src/cmd/internal/obj/arm64/asm7.go#L890 https://github.com/golang/go/blob/54789eff385780c54254f822e0... with the definitions of constants here: https://github.com/golang/go/blob/54789eff385780c54254f822e09505b6222918e2/src/cmd/internal/obj/arm64/7.out.go#L260 https://github.com/golang/go/blob/54789eff385780c54254f822e0... Another thing useful when debugging is using constants with non-overlapping peculiar ranges, rather than small integers, then simply by seeing a value in a debugger (or in a print of a value without a String() method), you'll know where that comes from.
  - sambeau 11y ago
    Thanks.

by 4ad 11y ago

sambeau 11y ago

> but even better is using negative values Honest question: Why?

4ad 11y ago
Most small values in programs are positive (lengths, counts, etc), so it's possible to write a value to something that should be initialised to a constant by mistake, and you'll never know, since the ranges overlap. But if you use negative values, and you write a positive value, when you see it, you'll know. Of course this is a very trivial thing, but it helped me many times. Sometimes it's better to use typed constants with a custom type, then the Go type system will help you and not let you assign things of a different type. Note that I only said sometimes, in many cases it's better to use untyped constants (or use primitive types rather than custom integers), and positive integers because you can calculate the constant corresponds to some value from a delta, or from some other criteria, like here: https://github.com/golang/go/blob/54789eff385780c54254f822e09505b6222918e2/src/cmd/internal/obj/arm64/asm7.go#L890 https://github.com/golang/go/blob/54789eff385780c54254f822e0... with the definitions of constants here: https://github.com/golang/go/blob/54789eff385780c54254f822e09505b6222918e2/src/cmd/internal/obj/arm64/7.out.go#L260 https://github.com/golang/go/blob/54789eff385780c54254f822e0... Another thing useful when debugging is using constants with non-overlapping peculiar ranges, rather than small integers, then simply by seeing a value in a debugger (or in a print of a value without a String() method), you'll know where that comes from.
- sambeau 11y ago
  Thanks.