Lucifers, I'm pleased to report that I've pushed some branches to the Clownfish and Lucy ASF repos which should make for a solid start on Go (golang) bindings.
http://s.apache.org/clownfish-go_bindings_1 http://s.apache.org/lucy-go_bindings_1 At present there is only just enough Lucy functionality to support a sample app, but that should be enough to allow for review. Compared with Philip Southam's "golucy" ( https://github.com/philipsoutham/golucy ) these bindings are incomplete, but place greater emphasis on solving some hard problems in Clownfish. Design notes: * Clownfish parcels are mapped 1:1 to Go packages -- i.e. there is only `lucy`, while `index`, `search`, `analysis` and the like are not broken out into separate packages a la Lucene's Java packages. * The Go package dir, which by convention takes the name of the package, has been put one level down from `go` -- e.g. `$LUCYREPO/go/lucy`. This allows us to put whatever junk we want into `go/`. * The build is powered by a Go "script" named "build.go". * Clownfish-powered code ends up linked statically into Go binaries -- avoiding all the permissions, versioning and deployment complications of dynamic linking to shared libraries outside of $GOPATH. * Clownfish headers get installed into a dedicated subdir of $GOPATH/pkg. * Clownfish exception handling has been implemented using Go's panic/recover/defer. * Idiomatic Go error handling is achieved by trapping exceptions in user-level method wrappers and returning an `error` alongside any return value. * Clownfish abstract classes are mapped to Go interfaces. * Clownfish concrete classes are mapped to Go struct pointers. * Constructors adopt Go naming conventions, e.g. `lucy.NewSchema()`. * Lucy documents are organized as Go structs. Field names are mapped case-insensitively and values are accessed using reflection techniques similar to those used by Go's `encoding/json` package. Challenges: * Adapting Clownfish's subtyping for Go is hard, because Go does not support inheritance. This is especially a problem with functionality which can only be unlocked by overriding methods on concrete classes like QueryParser, IndexManager and Schema. * Making Clownfish-powered packages "go-gettable" would be hard and the result would be inherently fragile. I think we should accept for the time being that it won't be feasible for either Clownfish or Lucy. We aren't the only people that have this problem, though. * Go data cannot be passed to C (because that interferes with Go dev plans to implement compacting garbage collection). Marvin Humphrey
