As mentioned previously, I'm interested in writing a .NET protocol
buffer compiler, which would initially generate C# code. I can
envisage three overall designs for this:
1) Write the generator in C++, like the Java one. Keep the generator
itself purely in native code.
Pros:
* No interop work required
* Can be run on machines with no CLI implementation
Cons:
* Same "you need to know C++" barrier to entry for the next .NET
language (more on this below)
* May involve quite a lot of C++, which I'm not hugely familiar with
2) Write a managed generator interface to the native protocol compiler
Pros:
* Managed interface can be used by other projects, e.g. to target
VB.NET, F# etc - or even non-.NET languages if the generator author
happens to prefer a .NET language to C++
* Most of the real generator code can be in C# :)
Cons:
* May require more detailed C++ and interop knowledge than I currently
have (i.e. less C++ code, but harder)
* Harder to run the same generator on all platforms
3) Write a managed protocol compiler from scratch
Pros:
* No nasty interop to worry about
Cons:
* Pain of forking and keeping it all up to date
* Wastes a lot of existing effort
* Lots of work!
Now, one question is whether any other generators for .NET languages
will really be needed. Once you've got C#, you can compile to a .NET
assembly and use that from any other .NET language, right? Well,
that's true - but there may be advantages in using the generated
source within a project instead of as a separate assembly:
1) The protocol buffers can be internal instead of public. In some
cases the PBs will be part of a public API, but in others they're just
an implementation detail which shouldn't be exposed.
2) With partial classes, PBs can start to gain behaviour without nasty
inheritance tricks. Obviously this is open to abuse, but I think in
some cases it will avoid creating unnecessary wrappers for data types
which really want to have some logic in them.
As you can't mix and match source languages within one assembly (at
the moment) it may be useful to have non-C# generators.
Any thoughts?
Jon