Skip to content
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

#184 unmarshaller shuffle #292

Open
wants to merge 19 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@blast-hardcheese
Copy link
Collaborator

commented May 11, 2019

Resolving #184

Contributing to Twilio

All third party contributors acknowledge that any contributions they provide will be made under the same open source license that the open source project is provided under.

  • I acknowledge that all my contributions will be made under the project's license.

@blast-hardcheese blast-hardcheese referenced this pull request May 12, 2019

Open

Fix issue 290. #291

1 of 1 task complete

@blast-hardcheese blast-hardcheese force-pushed the blast-hardcheese:184-unmarshaller-shuffle branch from e4b9c44 to fd4c02e May 13, 2019

@blast-hardcheese blast-hardcheese force-pushed the twilio:master branch from 6a41c95 to 3f0f265 May 15, 2019

@kelnos

kelnos approved these changes May 20, 2019

// Translate HttpEntity => Json (for `text/plain`, relying on the Decoder to reject incorrect types.
// This permits not having to manually construct ToStringMarshaller/FromStringUnmarshallers.
// This is definitely lazy, but lets us save a lot of scalar parsers as circe decoders are fairly common.)
final val sneakyJsonEntityUnmarshaller: FromEntityUnmarshaller[${jsonType}] =

This comment has been minimized.

Copy link
@kelnos

kelnos May 20, 2019

Member

sneaky! :D

required: Term => Type => Option[Term] => Target[Term],
multi: Term => Type => Option[Term] => Target[Term],
multiOpt: Term => Type => Option[Term] => Target[Term],
optional: Term => Type => Option[Term] => Target[Term]

This comment has been minimized.

Copy link
@kelnos

kelnos May 20, 2019

Member

Any readability concerns with a function-function-function?

This comment has been minimized.

Copy link
@blast-hardcheese

blast-hardcheese May 20, 2019

Author Collaborator

I tried to maintain the level of precedence for relevancy. I have no objections to this style.

That being said, an alternative would be a tuple or a named parameter with explicit unapply overrides to prevent every field needing to be explicitly updated any time anything changes with the source API.

@blast-hardcheese

This comment has been minimized.

Copy link
Collaborator Author

commented May 20, 2019

One major downside of this PR in its current state is that the "base" type is unable to be traversed for deferred datatypes. I'm updating the branch at this point, though I need to go back and reevaluate some of this approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.