3 ms·
I agree with you, but in the cases where it really matters you can still avoid it! There is community activity around code generation to fill in for the cases w
by gepoch 10y ago
I agree with you, but in the cases where it really matters you can still avoid it! There is community activity around code generation to fill in for the cases where generics would really be the right answer. Basically, you make a template and render it for your type, check that into source control, and use as normal.
This removes the dynamic overhead at the cost of having to run a code generator and maintain a rendered template library in your source. There's actually language support for hooking into these generators at build time.
- zzzcpan 10y ago> There's actually language support for hooking into these generators at build time. Hmm, are you talking about "go generate" or is there a new feature? Because go generate is not a build time hook, but build time hook would be very useful in some cases.
- CorvusCrypto 10y agoTo be honest, while the generate functionality has been helpful, I have to say it's fairly annoying to manage at times. It can be super tempting to create a new generation tool that writes "ugly" memory optimized code (a la the stringer example by Rob Pike) only to find out you need to debug that mess. In something like stringer it would be okay, but for something more complex, perhaps not. This is just a minor complaint. There is at least a workaround, even if the answer is still typing a bit more than if you used Templates/Generics.