On Mon, Dec 14, 2015 at 3:37 AM, Nick Wellnhofer <[email protected]> wrote:
> The other big feature in 0.5 are the Go bindings. Marvin, what's the
> status here? Do you think it's realistic to aim for a release early next
> year?
I'll be comfortable with the state of the Go bindings for an 0.5.0 release
after clearing out two action items:
1. Finish tuning and testing the Go bindings for Lucy (LUCY-282). I
estimate that this will be done within a week.
2. Write a README or two explaining the state of the Go bindings.
There remain four important features missing from Clownfish's Go support:
1. Generated documentation.
2. Subtyping.
3. Error handling via return types.
4. Support for typed collections, e.g. `[]string`.
Generated documentation is simply a TODO. The Lucy and Clownfish 0.5.0 Go
bindings will be almost entirely undocumented.
As we've discussed before, subtyping remains problematic. There are features
in Lucy that will be inaccessible from the 0.5.0 Go bindings, because you
need to subclass in order to get at them and you can't create a subclass
from Clownfishy Go bindings.
Error handling is something else we've talked about before. Idiomatic Go
APIs handle errors via returned `error` types, often utilizing Go's multiple
return values, which Clownfish and CFC do not yet support.
Finally, there are a number of places in Lucy or Clownfish where we return a
`Vector` or accept a `Vector` as a parameter and the elements belong to a
known uniform type. The expected mapping in Go would be a slice of that
uniform type. To solve this, we would need to add support for specifying
the interior type to the Clownfish header language -- e.g. allowing a
`Vector<String>` which could then be mapped to a Go `[]string` slice.
In LUCY-282, I've addressed both error handling and slice types by writing
manual bindings. This was a lot of work and we now have a lot of manual
binding code, but the great majority of it is code that can be deleted once
the Clownfish header language and CFC provide enough support to autogenerate
idiomatic binding code. In the meantime, this work will hopefully limit the
number of func-level breaking changes we have to make in the future,
minimizing churn for early adopters.
Marvin Humphrey
