Gopher Tricks
talks.golang.org
talks.golang.org
Every time I read a link mentioning "gopher" I expect it to be a neat hack based on the obsoleted protocol.
OR
1b. Install Lynx or eLinks
2. goto gopher://gopher.floodgap.com
I've been playing around with Gopher a bit lately. I installed eLinks just to have a Gopher client. I've even been thinking about setting up gopher://gopher.fogbeam.com to serve content over Gopher protocol. :-)
Every time I read a link mentioning "gopher" I expect it to be a neat hack based on the obsoleted protocol.
Came here to say the same thing. Every time I see one of these headlines, I expect something about Gopher[1], not Golang.
By Brad Fitzpatrick (another Go team member): https://code.google.com/p/gogopherd/
It'd be nice to have a shorthand which mixed the type definition and assignment into a single line so you could do something like:
S := { x int : 1, y int : 2 }
Or even
S:= { x := 1, y := 2 }
(Yes, I know Rob's and Ken's history with regards to C.)
---
I like the map. Here's the rules for Conway's Game of Life as a nested map:
var cgol = map[state]map[int]state{
alive: {
0: dead,
1: dead,
2: alive,
3: alive,
4: dead,
5: dead,
6: dead,
7: dead,
8: dead,
},
dead: {
0: dead,
1: dead,
2: dead,
3: alive,
4: dead,
5: dead,
6: dead,
7: dead,
8: dead,
},
}Before C, naturally no-one knew C.
Before Go though, tens of millions know C.
They are casually throwing away all of that familiarity in the name of elegance. I think this is what might mean that Go doesn't "win".
If you class doing basic design work and taking time to document it as "arrogance" then I'm afraid you may be suffering from negative mindset.
That looks like a good deal to me! :)
I can barely read this: void (signal(int, void (fp)(int)))(int);
I can read this easily: func signal(int, func(int)) func(int)
map[state]map[int]state -> a map of state keys pointing to maps of int keys pointing to states
"map of int to string"
map [int] string
"map of state to map of int to state"
map [state] map [int] state
( ...Any excuse to link to this excellent presentation: http://www.infoq.com/presentations/Simple-Made-Easy )
That's pretty cool.
package main
import "fmt"
// <Add one short line of valid Go code here>
func main() {
var n int = 1
fmt.Println(n)
}
Compiler: "prog.go:8: cannot use 1 (type int) as type int in assignment"
m := map[[]int]int{}Per the spec[0]:
The comparison operators == and != must be fully defined for operands
of the key type; thus the key type must not be a function, map, or
slice. If the key type is an interface type, these comparison
operators must be defined for the dynamic key values; failure will
cause a run-time panic.
"Map lookup requires an equality operator, which slices do not implement. They don't implement equality because equality is not well defined on such types; there are multiple considerations involving shallow vs. deep comparison, pointer vs. value comparison, how to deal with recursive types, and so on. We may revisit this issue—and implementing equality for slices will not invalidate any existing programs—but without a clear idea of what equality of slices should mean, it was simpler to leave it out for now.
In Go 1, unlike prior releases, equality is defined for structs and arrays, so such types can be used as map keys. Slices still do not have a definition of equality, though."
m := map[[]int]int{}
m := map[[3]int]int{}
To recap:
a := [3]int{1,2,3} // Array
b := a[:2] // Slice
var c []int = a[:] // Slice
var d [3]int // Array
copy(d[:], c) // Copy to (a slice of an) array from sliceAnother approach to take, which I think could be quite useful, is that if you use something modifiable as a key, then the map takes a snapshot of it when you perform the insert. That way, I can go and modify the key after the insert and any time thereafter if I look for the same sequence of integers, the map will find the associated value.
The problem here is that, in a language like Go, where pointer values are significant (contrast with Haskell, where two lists allocated separately but having the same contents are indistinguishable), you sometimes want to use pointer identity as the key so maybe it's hard to have it both ways.
Oh well. It's just something that surprises someone like me, who has grown accustomed to more value-oriented languages.
Anyway, here is a solution: http://play.golang.org/p/Mg8x7sJ-hR
In other words, just insert the following line:
type int string
There are other interesting cases. For example,
var true = false // Perfectly valid Go code!
For a list of all the predeclared identifiers, see here: http://golang.org/ref/spec#Predeclared_identifiers
If i compare to Objective-C "object respondsToSelector:selector()" or "object isKindOfClass" equivalent, this go "casting to an anonymous struct" code seems extremely convoluted.
Plus, i may be wrong, but it seems like it's really not robust. You're trying to cast to an anonymous struct declared locally, that isn't linked to any other interface anywhere, and only implements part of the methods defined in the File struct. It's looks to me just as robust as using strings. What you would like to express, is what's in the comment : aka, test against something related to the File struct/interface.