I'll make a different suggestion. There's been some chatter that schemas are a better tool than coders, and that in Beam 3.0 we should make schemas the basic semantics instead of coders. Schemas provide everything a coder provides, but also allows for far more readable code. We can't make such a change in Beam Java 2.X for compatibility reasons, but maybe in Go we're better off starting with schemas instead of coders?
Reuven On Thu, Jan 3, 2019 at 8:45 PM Robert Burke <rob...@frantil.com> wrote: > One area that the Go SDK currently lacks: is the ability for users to > specify their own coders for types. > > I've written a proposal document, > <https://docs.google.com/document/d/1kQwx4Ah6PzG8z2ZMuNsNEXkGsLXm6gADOZaIO7reUOg/edit#> > and > while I'm confident about the core, there are certainly some edge cases > that require discussion before getting on with the implementation. > > At presently, the SDK only permits primitive value types (all numeric > types but complex, strings, and []bytes) which are coded with beam coders, > and structs whose exported fields are of those type, which is then encoded > as JSON. Protocol buffer support is hacked in to avoid the type anaiyzer, > and presents the current work around this issue. > > The high level proposal is to catch up with Python and Java, and have a > coder registry. In addition, arrays, and maps should be permitted as well. > > If you have alternatives, or other suggestions and opinions, I'd love to > hear them! Otherwise my intent is to get a PR ready by the end of January. > > Thanks! > Robert Burke >
