Interim JDK 10 RFR of 8187951: Update javax.lang.model.SourceVersion for "var" name

[Jonathan Gibbons]

Joe,

I guess I would ask, who are these methods targeted at?

Both isIdentifier and isKeyword are fuzzy at best.

isIdentifier does not take the appropriate Unicode standard into 
account, although it is probably "good enough".

isKeyword has certainly become more complex in 9 and after, and anyone 
who really needs this info (e.g. IDEs) is probably already doing it for 
themselves, properly.

Do you have any reasonable use-cases for a fuzzy definition of 
isKeyword, or should we just deprecate it words the Big Bit Bucket in 
the sky?

-- Jon



On 9/29/17 10:41 AM, joe darcy wrote:
>
> Hi Maurizio,
>
> I agree that implementing a more precise version of the 
> can-I-use-this-as-a-name check requires more context, such as the 
> element kind as you suggest.
>
> My sense is that additional API scope isn't warranted. Within the 
> existing set of methods, I think having isName and isKeyword both 
> return "false" for var for RELEASE_10 and later would be acceptable.
>
> What to you think?
>
> Thanks,
>
> -Joe
>
>
> On 9/28/2017 1:35 AM, Maurizio Cimadamore wrote:
>>
>> Not 100% sure about this. On the one hand, the concept of contextual 
>> keyword is, well, associated with a context. So 'open' is a keyword 
>> in a module-info file, and 'var' is a keyword when used in a local 
>> variable declaration.
>>
>> But the isName method takes no such context, so it's bound to be lossy.
>>
>> You tried to reformulate the semantics of isName as something similar 
>> to 'is this a valid name for a javax.lang.model.element.Element 
>> instance'? I think that _almost_ works - after all elements model:
>>
>> * variables/fields (VariableElement)
>> * methods (ExecutableElement)
>> * classes/interfaces/enums/annotations (TypeElement)
>> * typevars (TypeParameterElement)
>> * modules (ModuleElement)
>> * packages (PackageElement)
>>
>> now, in the last two cases, I'm not sure the implemented logic works 
>> well. While 'var' is not a legal name for 
>> variables/methods/types/typevars, I think it is a valid name for 
>> packages and modules, there's no restriction there.
>>
>> This unfortunately makes the definition of isName messy, because it 
>> doesn't really refer to _all_ elements, but just to a subset of them.
>>
>> Also, I find this text:
>>
>> "and {@code "var"} is used for local variable type inference inthe 
>> argument version."
>>
>> I only got a good idea of what you meant by looking at the 
>> implementation.
>>
>> One alternative would be to mark this method as @Deprecated, and add 
>> a new method:
>>
>> public static boolean isName(CharSequence name, *ElementKind kind*, 
>> SourceVersion version) { ... }
>>
>> Where the semantics could be:
>>
>> is _name_ a valid qualified name for an element of kind _kind_ in 
>> version _version_ ?
>>
>> While not perfect (it still cannot handle module-info keyword, as 
>> there's no info on which compilation unit this question refers to), I 
>> think it's a step forward in that it lets you discriminate between 
>> different kind of elements.
>>
>> An even more complete variant would be:
>>
>> public static boolean isName(CharSequence name, *JavaFileObject 
>> sourceFile, ElementKind kind*, SourceVersion version) { ... }
>>
>> Which would let you express in full what you need to express, for 
>> both 'var' and module keywords.
>>
>> Maurizio
>>
>> On 27/09/17 23:51, joe darcy wrote:
>>> Hello,
>>>
>>> Please review the in-progress work on
>>>
>>>     8187951: Update javax.lang.model.SourceVersion for "var" name
>>> http://cr.openjdk.java.net/~darcy/8187951.0/
>>>
>>> I'm not 100% certain of the desired semantics here. The handling of 
>>> "var" doesn't align with any of the existing syntactic constructs, 
>>> including restricted keywords introduced in 9 with modules.
>>>
>>> The proposal changes gives the "isName" method the semantics of "can 
>>> I use this qualified name for a type, field, package, or module."
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170929/8fd9dfbb/attachment-0001.html>