Open 7sharp9 opened 5 years ago
Basically this: https://github.com/ctaggart/froto/blob/ba4d5e506e1be6105dc6746a08a1d6714793e8fe/TypeProvider/Core/Message.fs#L10-L19
Becomes an interface defined in Froto.Serialzation
The Message implementation can still live in froto/TypeProvider/Core/Message.fs
just it implements the interface, then other code generators have a point or reference implementation.
Any thoughts @ctaggart / @jhugard
Basically I just want that interface in the first comment to be defined here.
Sounds quite reasonable. Should IMessage also define a WriteTo
?
The interface I suggested was based on what's implied via the srtp method constraints.
On Fri, 31 Aug 2018 13:57 James Hugard, notifications@github.com wrote:
Sounds quite reasonable. Should IMessage also define a WriteTo?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ctaggart/froto/issues/91#issuecomment-417655739, or mute the thread https://github.com/notifications/unsubscribe-auth/AAj7yjfUdGnTHMsx8Yc491E2tZjutu2cks5uWTLTgaJpZM4V-QYP .
Currently when you are generating code you have to make a dependency on Froto.serialization which if fine, its the serialization lib after all, but then you also have to include Froto.codec too as you have to have a concrete interface or rely completly on SRTP which is not always easy and gets rapidly more complex if you have to add reflection into that mix. Having the interface as a hard reference in Froto.Serialization means you can more or less eliminate Froto.Codec from the type provider implementation and any custom code gen, which is what I have been doing. Ive been whittling away Froto.Codec but now Ive come to the point where the basic interface implementation of IMessage needs to have a home.