Timeline for Is source code generation an anti-pattern?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 17, 2020 at 12:55 | history | made wiki | Post Made Community Wiki by maple_shaft♦ | ||
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| Nov 29, 2017 at 23:47 | comment | added | jaskij | @PaŭloEbermann done | |
| Nov 29, 2017 at 23:43 | history | edited | jaskij | CC BY-SA 3.0 | Add additional info on why protocol buffers benefit from code generation. |
| Nov 29, 2017 at 23:25 | comment | added | Paŭlo Ebermann | I agree ... could you add this into the answer? | |
| Nov 29, 2017 at 23:21 | comment | added | jaskij | @PaŭloEbermann apart from the usual perfromance argument such a generic interpretation would make it impossible to use those messagess as first-class objects in compiled (and possibly interpreted) languages - in C++ for example such an interpreter would by necessity return a key-value structure. Of course you can then get that kv into your classes but it can turn into a lot of boilerplate code. And there is also code completion too. And compile time checking - your compiler won't check if your literals don't have typos. | |
| Nov 29, 2017 at 23:12 | comment | added | Paŭlo Ebermann | For the first reason, I think the OP's idea would be to have a generic implementation in each language (which takes the protocol buffers description and then parses/consumes the on-the-wire format). Why would this be worse than generating code? | |
| Nov 29, 2017 at 7:35 | history | answered | jaskij | CC BY-SA 3.0 |