Java: Add aliases for CodeQL classes with unintuitive name #14555
Replies: 1 comment 1 reply
-
|
We did MethodCall, VarWrite, VarRead and NewClassExpr (which is smaller than ClassInstanceExpr, excluding implicit creation) in #14575 |
Beta Was this translation helpful? Give feedback.
-
|
Oh wow, thanks a lot! I initially only hoped to get a discussion started and maybe to have these added as additional aliases, but it is great that you apparently liked this suggestion and directly implemented the changes. For Unfortunately it looks like documentation (including screenshots) is also affected by these changes: |
Beta Was this translation helpful? Give feedback.
-
Description of the issue
There are CodeQL classes for Java whose name are not that intuitive and which might therefore make it more difficult for users to discover and to understand what they do.
MethodAccessMethodCallCall. And this basically seems to be a "method call". "access" sounds a bit too unspecific, for example a method reference expression is not aMethodAccess(its synthetic anonymous class has aMethodAccessthough) but one could think it is based on the name.LValue,RValueVarWrite,VarReadVarAccess; other subclasses are namedFieldWrite,FieldRead. The termsLValue,RValueare not / rarely used in the context of Java. The only mention in the JLS seems to be a comparison with C ("in C, this would be called an lvalue").ClassInstanceExprNewExpr?(probably needs a better name since this does not cover creation of arrays which also uses
new)MemberRefExprMethodRefExpr?What do you think?
This is only a rough suggestion for now, I haven't considered all aspects of this yet such as whether it would make sense to deprecate the existing names eventually, whether the two separate names will increase confusion, or how to deal with subclasses or predicates using the same (unintuitive) name.
I just wanted to generally hear what you think about this.
Beta Was this translation helpful? Give feedback.
All reactions