4 ms·
> (by someone who invariably thinks they are sooooo smart for discovering it), not as a real problem preventing compilation of a real schema That's a pretty di
by colanderman 7y ago
> (by someone who invariably thinks they are sooooo smart for discovering it), not as a real problem preventing compilation of a real schema
That's a pretty dismissive view of your users. This has actually bitten me in practice, so consider their foresight vindicated.
(Notably, it was actually the inability to easily distinguish between a missing and empty array, which caused us to resort to using "has_foo" fields, only later to hit the issue with the C++ compiler.)
If you dismiss this as a valid concern, how can I be confident that there are not other similar issues you simply dismissed as unimportant?
Say what you will about STL, but the level of attention to detail there assures me that I'm not likely to get bitten by some weird issue the developers chose to turn a blind eye to.
> you can say that "has_foo" should be renamed to "has_foo_" (or whatever) in C++ generated code.
This is fine, even if it's a transformation predetermined by the language.
- kentonv 7y agoSorry for the snark. This issue is a sore spot for me because so many people have reported it without having actually been affected by it, and because they tend to assume the designers were stupidly unaware of the issue, rather than that the issue is actually rather hard to solve in a satisfying way. However, if you actually were affected by it, then you are right to be annoyed by it. The particular case where someone developed a protocol mostly in one language and then later on started targeting a new language is indeed a case that I do worry about. The idea of language-specific annotations defining language-specific renames was designed for that use case. I haven't worked on Protobuf in almost a decade, but Cap'n Proto does address this issue as I said -- without making everyone's code horribly ugly.