This repository has been archived by the owner on Feb 8, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 27
Add interface implementation of IMessage to Froto.Serialiation to make code gen have less dependencies #91
Labels
Comments
Basically this: froto/TypeProvider/Core/Message.fs Lines 10 to 19 in ba4d5e5
Becomes an interface defined in Froto.Serialzation |
The Message implementation can still live in |
Basically I just want that interface in the first comment to be defined here. |
Sounds quite reasonable. Should IMessage also define a |
The interface I suggested was based on what's implied via the srtp method
constraints.
…On Fri, 31 Aug 2018 13:57 James Hugard, ***@***.***> 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
<#91 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAj7yjfUdGnTHMsx8Yc491E2tZjutu2cks5uWTLTgaJpZM4V-QYP>
.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: