Skip to content
This repository has been archived by the owner. It is now read-only.

Check generic signatures #163

Closed
jodastephen opened this Issue Dec 11, 2012 · 14 comments

Comments

4 participants
@jodastephen
Copy link
Member

jodastephen commented Dec 11, 2012

Ensure that the generics used are correct. This is specifically focussed on extends/super.

For example, the Chrono static comparators should perhaps use extends.

@jodastephen

This comment has been minimized.

Copy link
Member Author

jodastephen commented Jan 31, 2013

I've examined the generics on the temporal classes twice now. It isn't possible to enhance their generics without making a terrible mess. Because Java doesn't have the Self-type generic, or the notional of parameter self-type generic where the class is final, and because LocalDate extends ChronoLocalDate, it is more or less impossible to go further than we have. This is unfortunate, but there you go.

The call remains open to check ? extends and ? super.

@jodastephen

This comment has been minimized.

Copy link
Member Author

jodastephen commented Feb 1, 2013

TemporalUnit <R extends Temporal> long between(R dateTime1, R dateTime2); has no effect on callers. It doesn't do what I'd like it to do. Needs to be ungenerified.

@RogerRiggs

This comment has been minimized.

Copy link
Contributor

RogerRiggs commented Feb 1, 2013

It should insist that the parameters are of the same/compatible types.
What is it not doing?

@jodastephen

This comment has been minimized.

Copy link
Member Author

jodastephen commented Feb 1, 2013

This compiles, rather than being a compile error:

 Instant i = ...
 ZonedDateTime z = ...
 between(i, z)
@RichardWarburton

This comment has been minimized.

Copy link
Contributor

RichardWarburton commented Feb 2, 2013

It only insists that they have a common supertype that subclasses temporal
I think.

@RogerRiggs

This comment has been minimized.

Copy link
Contributor

RogerRiggs commented Feb 2, 2013

It makes sense to remove the generics, they are more useful in the case where the return type is related to the parameters.

@RogerRiggs

This comment has been minimized.

Copy link
Contributor

RogerRiggs commented Feb 3, 2013

The generics should be removed from Chronology.getAvailableChronologies(). The raw types are just as useful.

@jodastephen

This comment has been minimized.

Copy link
Member Author

jodastephen commented Feb 3, 2013

I don't think we should have raw types in API signatures. I would have thought there was a JDK/Oracle policy against it.

@ijuma

This comment has been minimized.

Copy link

ijuma commented Feb 3, 2013

It would be very odd for a brand new API to have raw types in API signatures in my opinion.

@RichardWarburton

This comment has been minimized.

Copy link
Contributor

RichardWarburton commented Feb 3, 2013

Quite a few people compile with warnings switched on for raw types, this
would generate a lot of warnings for me. Perhaps a simple ? wildcard would
be a better solution if you're leaving generics in.

@jodastephen

This comment has been minimized.

Copy link
Member Author

jodastephen commented Feb 4, 2013

@jodastephen

This comment has been minimized.

Copy link
Member Author

jodastephen commented Mar 23, 2013

Chronology returns raw types for ChronoLocalDate which needs fixing.

@RogerRiggs

This comment has been minimized.

Copy link
Contributor

RogerRiggs commented Mar 26, 2013

@RogerRiggs

This comment has been minimized.

Copy link
Contributor

RogerRiggs commented Jan 21, 2014

Nothing more to do on this.

@RogerRiggs RogerRiggs closed this Jan 21, 2014

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.