On Wed, 28 Oct 2020 08:54:31 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> Some thoughts regarding the parameter type of refersTo. Summary: I think >> `refersTo(T)` is fine and that we don't want to change it to >> `refersTo(Object)`. >> >> I don't think we have a migration issue similar to generifying collections, >> where there was a possibility of changing `contains(Object)` to >> `contains(E)`. If that had been done, it would have been a source >> compatibility issue, because changing the signature of the method >> potentially affects existing code that calls the method. That doesn't apply >> here because we're adding a new method. >> >> The question now falls to whether it's preferable to have more convenience >> with `refersTo(Object)` or more type-safety with `refersTo(T)`. With the >> generic collections issue, the migration issue probably drove the decision >> to keep `contains(Object)`, but this has resulted in a continual set of >> complaints about the lack of an error when code passes an instance of the >> "wrong" type. I think that kind of error is likely to occur with `refersTo`. >> Since we don't have a source compatibility issue here, we can choose the >> safer API and avoid this kind of problem entirely. >> >> The safer API does raise the possibility of having to add inconvenient >> unchecked casts and local variables in certain places, but I think Mandy's >> comment about the code already having a reference of the "right" type is >> correct. Her prototype webrev linked above shows that having to add >> unchecked casts is fairly infrequent. > >> Some thoughts regarding the parameter type of refersTo. Summary: I think >> `refersTo(T)` is fine and that we don't want to change it to >> `refersTo(Object)`. >> > I agree that we don't have a migration problem here that collections had. So > let it be `refersTo(T)` then. I agree as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/498
