lostluck commented on issue #21929: URL: https://github.com/apache/beam/issues/21929#issuecomment-1159121423
I like the general thrust of this suggestion! There's plenty to do to use generics with beam (see Beam Java's probable over-abundance of Generics). Currently we have the goal to carefully add generics without breaking existing code. First as Danny points out is the generic registrations, which make it easier to improve performance by removing per-call execution time reflection. We'd also like to introduce a "real" KV type, and make sure that's understood by the whole framework. No more splitting KVs (except to support older code). Similarly, generic iterator and emitters types would let the Go compiler do more work for inlining and efficient calls. While we're Making the "front end" generic with typed PCollections is difficult once one gets to features like Side Inputs. I don't see fully compile time checked side inputs in the near term. Either way, it's important to note that while the SDK's core will take time to include generic awareness, user DoFns and transforms will be able to take advantage of them much sooner. All that said, something like the code in this example, could be added to a package under ...pkg/beam/x/.. so we can allow users to experiment with them before we fully commit to a given wrapper/approach. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
