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
gen
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,
