lostluck commented on pull request #12059: URL: https://github.com/apache/beam/pull/12059#issuecomment-648317098
1. Not while I'm in the middle of modifying all the coder code for Schemas :D 2. As you've described, there's a reason for the two packages, one is for Beam Model coders, and the other is for *not* beam model coders. That signal is valuable though I agree it's a bit subtle, and not called out very well. It's the kind of thing that I'd have called out in a document of a walkthrough of the Go SDK, but didn't in my talk. The value is that it's harder to accidentally use a non-standard coder when one must use a standard one. By being separate, they also serve as an example of how to write some of these. I do agree that the runtime folder is probably not the right place for the coderx package though. It's also a bit moot since it's not a package users will interact with. If we were to get rid of the coderx package, I'd rather the coders move to the main beam package or similar, since they're invoked in inferCoders IIRC? These are good things to think about, and the whole SDK could use a clear overhaul, but we should have a total plan for that so we can apply them evenly to all facets of the SDK at once, rather than one at a time. Note, that this would probably need to wait until a beam v3 or similar, as disrupting so many packages would break folks who are importing them for some reason out of the SDK. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
