Optionally trading performance for smaller generated code footprint?

[josephbuchma]

How difficult would it be to add following optional features?

• Use runtime router instead of code-generated static radix;
• Use runtime (reflection-based) json encoding instead of code-generated jx encoders/decoders;
• Use go's generics for Opt[T], Nil[T], OptNil[T] (this one isn't something you can just turn off once it was enabled, but there is no performance penalty, so this can become a default behavior at some point, maybe).

[kszafran]

I'm interested in this, too. Having lots of generated code slows down local development and CI pipelines when combined with other code generation tools and/or linters that need to parse all that ogen-generated code.

I'm currently experimenting with adding generic Opt/Nil/OptNil types. I think it'll still be possible to handle encoding/decoding without using reflection. Replacing it altogether with the standard json package would also be interesting as an option, although not something I'm considering at the moment.

I'd also like to get rid of getters and setters that get generated for all fields. I'm not too worried about the router code, but I think it should be possible to reduce code duplication in request handlers.

However, I'm not sure what maintainers think about this. Changes like using generic Opt/Nil/OptNil types or reflection-based encoding/decoding effectively mean that you need to support 2-3 different ways of doing the same thing. @ernado @tdakkota