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

BVAL-508 Second round with both alternatives #23

Closed

Conversation

emmanuelbernard
Copy link
Member

This second round offers improvement on the initial proposal (called proposal 1)

  • address remarks from the PR
  • cover Map<@notempty String, @min(5) Integer>
    • introduce notion of container + value type tuple for a given extractor and @ExtractedValue
  • detail refinements necessary for @Valid on type_use

It also includes Gunnar's proposal (proposal 2). Gunnar's proposal does not go into all of the nasty details though, so this round of review will need to pounce this aspect.

@emmanuelbernard
Copy link
Member Author

Test


Extractors for the specific tuple container and value type can be implemented.

TODO: should we differentiate single and plural?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's good for the sake of perf - no Iterable allocation in the singular case.

@emmanuelbernard
Copy link
Member Author

Replacement for #20

* address remarks from the PR
* cover Map<@notempty String, @min(5) Integer>
** introduce notion of container + value type tuple for a given
extractor and `@ExtractedValue`
* detail refinements necessary for @Valid on type_use
@gunnarmorling
Copy link
Member

@emmanuelbernard I've sent PR emmanuelbernard#1 against your repo with an update to my alternative. Overall I think we can continue discussion based on yours, as you say the have converged more or less. The only difference being support for unknown generic containers in my proposal, but I think that's sufficiently covered in your one with the possibility for providing a custom extractor in such cases.

@gunnarmorling
Copy link
Member

@emmanuelbernard, any thought? Do you think we can merge it (with the changes I made and sent as PR against your repo)?

@DavideD DavideD closed this Feb 23, 2016
@emmanuelbernard
Copy link
Member Author

Applied to production and converted to asciidoc

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

Successfully merging this pull request may close these issues.

None yet

3 participants