Hi all,

I was wondering if any thought has gone into generating an interface to go 
along with the generated data classes from a proto.
And if it had been considered were there any reasons to not do it?

Quick sketch of my current situation:

I have a project that has a complex and messy internal data structure 
(assume for now its too expensive to refactor).
On top of this I created an interface that already bears semblance to a 
.proto model we use. And an implementation of this interface which has a 
reference to an internal object and 'transmutes' the data from the internal 
model to the external format. So aside from the reference to the internal 
object, no data is held by the interface implementation. It basically acts 
as an adapter.

The implemented getters/setters allow the transmutation of internal data 
structures to 'external' structures

I am now however looking into simply generating this interface and part of 
the implementation to allow this model to be exported easily, while still 
having a clean API, which would (in time) also allow for code written 
against the generated API (also C++/python) to be portable.

For this I've been hacking away a bit at the C# proto generation code in an 
effort to generate something that would fit into the design below:


What I've done so far

   - Added a mirror of csharp_reflection_class as 
   csharp_reflection_interface (ReflectionInterfaceGenerator)  to generate 
   what I would like my interface to look like
   - Added interface-ended generation options to protoc cli 
   ie. --csharp_opt=generate_interface=true
   - Changed/added namespaces to use in generation (because in my case, the 
   interface is in a different namespace than the implementation)
   - Added a way to extract (ie not generate) property get;set; (similar to 
   how https://silentorbit.com/protobuf/ generates from proto), the developer 
   will need to implement these themselves, but having the interface enforces 

Now there are a number of open questions/issues that I thought proto 
devs/experienced C# developers might be able to weigh in.

   1. In various areas, the package name defined in the .proto is used as a 
   way to create the namespace, types etc which aren't even overwritten by 
   the --csharp_opt=base_namespace=... option. and it (seems) requires a C# 
   specific option in the .proto (option csharp_namespace =...) Is this 
   something I should definitely not overwrite/force, or can I freely change 
   namespaces of generated files without problems in later 
   2. Proto doesn't actively support inheritance causing each C# object to 
   hold derived object instances. This is currently all generated out, but for 
   any OO language it doesn't make any sense to have this in a design. But 
   these are still generated as-is. I've considered custom proto markup 
   extensions to mark these types as being derived to ignore them in 
   generation of the interface (not implementation), but I'm unsure whether 
   there are better ways to go about this.
   3. The implementation explicitly generates private fields for each 
   property and some code (Equals / GetHash etc) use these fields directly. 
   For my purpose however I don't need/want these fields, instead the 
   implemented accessors should be used. Would this cause any problems with 
   the generated code (after moving all field usage to accessor usage)?

Are there any alternative solutions that I've missed, would any of this 
work be in any way/shape form be useful for the Proto C# generation 

Thoughts, ideas, suggestions?


You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to