This is really great, and a very good idea to document. Going from "what
does a DoFnSignature and DoFnInvoker look like for a particular DoFn" is
super useful to even explain why these constructions exist. And from there,
you can talk about what the bytecode looks like and what the ByteBuddy to
Neat! I remember passing long time trying to decipher the DoFnInvoker
behavior so this will definitely be helpful.
Maybe a good idea to add the link to the Design Documents list for future
reference
https://cwiki.apache.org/confluence/display/BEAM/Design+Documents
On Wed, Jan 10, 2024 at 9:15 PM
That's neat! Thanks for writing that up!
On Wed, Jan 10, 2024, 11:12 AM John Casey via dev
wrote:
> The team at Google recently held an internal hackathon, and my hack
> involved modifying how our ByteBuddy DoFnInvokers work. My hack didn't end
> up going anywhere, but I learned a lot about how
The team at Google recently held an internal hackathon, and my hack
involved modifying how our ByteBuddy DoFnInvokers work. My hack didn't end
up going anywhere, but I learned a lot about how our code generation works.
It turns out we have no documentation or design docs about our code
generation,
