JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces

[Jonathan Gibbons]

Ron,

On the face of it, that sounds like a good idea, but (1) this RFE was 
mostly about improving docs and (2) in many cases, the possibility of 
ErrorType forces the return type to be TypeMirror.

If we could easily determine the most specific subtype for each method, 
that might be a good, separate enhancement.

-- Jon


On 05/30/2019 10:44 AM, Ron Shapiro wrote:
> Is it within scope to return the specific subtypes as covariant return 
> types? e.g. TypeParameterElement could return TypeVariable, 
> TypeElement could return DeclaredType, etc.
>
> On Thu, May 30, 2019 at 1:25 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>
>
>     On 05/30/2019 10:15 AM, Jonathan Gibbons wrote:
>     >
>     >
>     > On 05/29/2019 05:24 PM, Joe Darcy wrote:
>     >> Hello,
>     >>
>     >> Please review the webrev and CSR for:
>     >>
>     >>     JDK-8224687: Add clarifying overrides of Element.asType to
>     more
>     >> specific subinterfaces
>     >>     webrev: http://cr.openjdk.java.net/~darcy/8224687.2/
>     <http://cr.openjdk.java.net/%7Edarcy/8224687.2/>
>     >>     CSR: https://bugs.openjdk.java.net/browse/JDK-8225027
>     >>
>     >> Thanks,
>     >>
>     >> -Joe
>     >>
>     >
>     > Joe,
>     >
>     > CSR Reviewed.
>     >
>     > In the new test, I don't understand lines 119, 128, regarding
>     > ElementKind.FIELD.
>     > Either the code is a copy-paste error, or the description
>     elsewhere of
>     > DeclaredType
>     > and TypeKind.DECLARED is incorrect, since these only refer to
>     declared
>     > types
>     > (class, interface, etc) and not fields.
>     >
>     > Surprising or maybe not, the test actually passes, suggesting that
>     > this is the
>     > current behavior even if it is unexpected.  That being said, the
>     > output from the
>     > test would be easier to understand if it included the
>     ElementKind and
>     > simple name
>     > of the element, as well as the typeMirror, typeMirror class and
>     typeKind.
>     >
>     > -- Jon
>
>     I guess what is happening is that the mapping to TypeMirror for
>     ElementKind.FIELD
>     varies, depending on the field being declared. If so, that deserves
>     mention in the
>     spec for VariableElement.asType, and also deserves a comment in
>     the test
>     code.
>     I'll stop short of suggesting that the test code should have more
>     fields
>     in it, such as
>     a field of primitive type, but if you could find an easy way to adapt
>     the test for that,
>     that would be good too.
>
>     -- Jon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190530/4a7b78dc/attachment.html>