-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add methodOptions
to HasMethodImpl
to provide custom method options.
#331
Conversation
Next up: encode the MethodOptions as a string and decode it lazily
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but there seems to be a redundant pattern matching error with some GHC versions.
Fixed; PTAL. It turns out the test (which relied on GHC's overlapping pattern matching) wasn't catching errors correctly:
It was worse on newer GHC, but even on older ones it missed a misuse of
I fixed it by just calling |
We're not using it currently. Also, the existing approach doesn't work well with our internal Blaze rules. If we still want this long-term, we can revisit it after fixing #334.
We're not using it currently. Also, the existing approach doesn't work well with our internal Blaze rules. If we still want this long-term, we can revisit it after fixing #334.
We're not using it currently. Also, the existing approach doesn't work well with our internal Blaze rules. If we still want this long-term, we can revisit it after fixing #334.
We're not using it currently. Also, the existing approach doesn't work well with our internal Blaze rules. If we still want this long-term, we can revisit it after fixing #334.
…ns. (google#331) We provide the whole proto message, rather than pulling off individual fields. The set of fields may change for different builds of proto-lens (or based on extensions, though we can't see those directly due to google#27). Internally, we save the proto message in the source file as an encoded string, and decode it into a Haskell type lazily.
We're not using it currently. Also, the existing approach doesn't work well with our internal Blaze rules. If we still want this long-term, we can revisit it after fixing google#334.
…ns. (google#331) We provide the whole proto message, rather than pulling off individual fields. The set of fields may change for different builds of proto-lens (or based on extensions, though we can't see those directly due to google#27). Internally, we save the proto message in the source file as an encoded string, and decode it into a Haskell type lazily.
We're not using it currently. Also, the existing approach doesn't work well with our internal Blaze rules. If we still want this long-term, we can revisit it after fixing google#334.
We provide the whole proto message, rather than pulling off individual fields. The set of fields may change for different builds of proto-lens (or based on extensions, though we can't see those directly due to #27).
Internally, we save the proto message in the source file as an encoded string, and decode it into a Haskell type lazily.