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 <https://lh3.googleusercontent.com/-LPnAOgNI6qI/WS1B829DxdI/AAAAAAAAARg/COlh2p8vlSU4TauSGd96nqwTLHt-whPQACLcB/s1600/original_api.png> 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: <https://lh3.googleusercontent.com/-W9dYNFWYiGo/WS1ULo7tEDI/AAAAAAAAASA/tye3h_IcU7cEhViEXJhzSDO95k92SLlPgCLcB/s1600/generated_api.png> 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 it. 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 serialization/deserialization? 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 mainline? 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
