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

Deprecate .as[A] method for decoding #786

Closed
vkostyukov opened this issue Jun 9, 2017 · 6 comments
Closed

Deprecate .as[A] method for decoding #786

vkostyukov opened this issue Jun 9, 2017 · 6 comments

Comments

@vkostyukov
Copy link
Collaborator

The .as[A] method should only be supported for HList => A conversion (through the Generic instance). As far as the API changes go, I see the following migration schema:

  • param("foo").as[A] becomes param[A]("foo")
  • Should we do the same for headers? How popular is that to read non-string values out of headers?
@vkostyukov vkostyukov added this to the Finch 0.16 milestone Jun 9, 2017
@vkostyukov vkostyukov changed the title Get rid of .as[A] method for decoding Deprecate .as[A] method for decoding Jun 12, 2017
@vkostyukov vkostyukov modified the milestones: Finch 0.17, Finch 0.16 Aug 23, 2017
@sergeykolbasov
Copy link
Collaborator

sergeykolbasov commented Aug 26, 2017

Going to pick up this one if it's ok.

Just to make it clear: .as for HList => A should stay untouched, right?

@spockz
Copy link

spockz commented Aug 27, 2017

Should we do the same for headers? How popular is that to read non-string values out of headers?

The only cases I know are authentication and.., just authentication.

@rpless
Copy link
Collaborator

rpless commented Aug 31, 2017

Yes, iirc, .as for HList => A should stay the same. I think we should include headers with this, because would be a more consistent API and there are use cases for numbers and (maybe UUIDs) being in headers.

@vkostyukov
Copy link
Collaborator Author

Yeah, I guess the idea end state we want to be in is to keep as[Foo] as only a syntax extension for HList => Foo conversion.

I think I played with it in the past and turns out supporting a deprecation cycle would be a huge pain.

@vkostyukov
Copy link
Collaborator Author

Looks like we also need to add multipartAttribute to the list.

@vkostyukov
Copy link
Collaborator Author

I'm closing this for now as I'm not sure we have to wait for multipartAttribute to support a new pattern. The multipart* API is quite new and I think it's actually quite fine to wait a couple of more iterations before evolving it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants