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

Period conversion support should not be public #21574

Closed
snicoll opened this issue May 26, 2020 · 10 comments
Closed

Period conversion support should not be public #21574

snicoll opened this issue May 26, 2020 · 10 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@snicoll
Copy link
Member

snicoll commented May 26, 2020

StringToPeriodConverter is at odds with other converters at the moment (being public and not flagged final).

2.3.0 is out so that would be a breaking change.

@snicoll snicoll added for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels May 26, 2020
@snicoll
Copy link
Member Author

snicoll commented May 26, 2020

Discussing this with @jhoeller a bit more, I think we should expand the scope a bit. I thought initially that it is possible to register more than one Converter for the same pair and return null if the input can't be handled to let another converter try. That would be an elegant solution if one had to support a slightly different format, registering theirs before ours. Turns out only one converter per pair is supported.

If our converter is not a straightforward call, we should consider:

  • Making the converter public
  • Moving the conversion logic to a public API so that others can reuse it in their custom implementation.

@OrangeDog
Copy link
Contributor

OrangeDog commented May 26, 2020

The conversion logic in this case is almost public: PeriodStyle.detectAndParse(String, ChronoUnit).
However, that doesn't account for the @PeriodFormat or @PeriodUnit annotations that the converter also uses.

@philwebb
Copy link
Member

I think for now we should risk making this one package private in 2.3.1. The chances of anyone extending it yet are pretty slim.

@philwebb
Copy link
Member

If our converter is not a straightforward call, we should consider...

My feeling is that the converters are generally not designed to be subclasses or extended so we should keep them package private and not offer any public API. At least, not until someone specifically asks us to.

@philwebb philwebb added this to the 2.3.1 milestone May 26, 2020
@philwebb philwebb added the type: bug A general bug label May 26, 2020
@philwebb philwebb modified the milestones: 2.3.1, 2.3.x May 26, 2020
@philwebb philwebb removed the status: waiting-for-triage An issue we've not yet triaged label May 26, 2020
@snicoll
Copy link
Member Author

snicoll commented May 26, 2020

At least, not until someone specifically asks us to.

@OrangeDog did for the duration support on Gitter which triggered this issue when I was telling him the exact same thing and noticed the Period one was inconsistent.

@snicoll snicoll removed the for: team-attention An issue we'd like other members of the team to review label May 26, 2020
@philwebb
Copy link
Member

I missed that conversation, is there more context for why the override was required?

@OrangeDog
Copy link
Contributor

OrangeDog commented May 26, 2020

I was doing this

one had to support a slightly different format, registering theirs before ours.

and wanted a public constructor so I could delegate to an instance independently of a ConversionService.

And then I found DurationStyle.detectAndParse(String, ChronoUnit) and used that.

@snicoll
Copy link
Member Author

snicoll commented May 27, 2020

Alright so case closed and let's make this one consistent. Thanks both.

@snicoll snicoll changed the title Consider making StringToPeriodConverter final and package protected Period conversion support should not be public May 27, 2020
@snicoll snicoll self-assigned this May 27, 2020
@snicoll snicoll modified the milestones: 2.3.x, 2.3.1 May 27, 2020
@OrangeDog

This comment has been minimized.

@snicoll

This comment has been minimized.

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

No branches or pull requests

3 participants