Add interface implementation of IMessage to Froto.Serialiation to make code gen have less dependencies

[7sharp9]

    type IMessage =
        abstract member SerializedLength: unit -> uint32
        abstract member Serialize: ZeroCopyBuffer -> unit
        abstract member ReadFrom: ZeroCopyBuffer -> unit

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.

[7sharp9]

Basically this:

froto/TypeProvider/Core/Message.fs

Lines 10 to 19 in ba4d5e5

	type Message() =
	member this.SerializedLength =
	let buffer = NullWriteBuffer()
	this.Serialize buffer
	buffer.Length
	abstract Serialize: ZeroCopyBuffer -> unit
	abstract ReadFrom: ZeroCopyBuffer -> unit

Becomes an interface defined in Froto.Serialzation

[7sharp9]

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.

[7sharp9]

Any thoughts @ctaggart / @jhugard

[7sharp9]

Basically I just want that interface in the first comment to be defined here.

[jhugard]

Sounds quite reasonable. Should IMessage also define a WriteTo?

[7sharp9]

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> .