Closed Ericson2314 closed 11 years ago
I wonder if it wouldn't be better to use the same generic machinery instead.
That also works, but then any hand-rolled SerialLE or -BE instance is ignored.
It seems like it comes down to the same story as on IRC, if the user only supplies one of SerialBE or SerialLE then SerialHost could break.
One idea might be to fix this by doing more refactoring. If we merge SerialBE and SerialLE into a SerialEndian with both
serializeBE
and serializeLE
then serializeHost
has no issue and can likely be defined in the same class!
This has the problem that it makes you redo most of the work you just did, but it reduces from 4 classes to 2.
Oh, so the big and little endian methods are in the SerialEndian class, and the host are either also in that class with default instances or separate functions?
That sounds good to me.
Combined the classes. Only issue is that the fixed endian methods for Int
and Word
are defined with fail, as there is now no way to define the -Host methods without defining the -BE and -LE methods.
Did you see second commit in this pull request, @ekmett?
Merged.
Excellent! Anything else that needs to be done before pushing a new version to Hackage?
I mostly just intend to go through it with Stephen Compall on Monday and make sure we didn't miss anything obvious.
Sent from my iPhone
On Sep 8, 2013, at 5:14 PM, John Ericson notifications@github.com wrote:
Excellent! Anything else that needs to be done before pushing a new version to Hackage?
— Reply to this email directly or view it on GitHub.
Ok. Hope everything looks good then.
The choice between those two classes is made with CPP. Library users can still provide an instance for
SerialHost
that is distinct from both that fromSerialBE
andSerialLE
, just as before.