AutoCommon: check visibility of one method (or type or field) from another. #226
Labels
Comments
|
Absolutely. The only problem is that that is a large and somewhat complicated part of the JLS to implement. :\ It's certainly on the TODO list, but like GWT, we've just been limping along until a sufficiently tricky issue forces us into solving this problem. |
|
Actually, I believe use-cases in auto-common would always have a source of type public static boolean isVisibleFrom(Element target, PackageElement from) {
switch (Visibility.effectiveVisibilityOfElement(target)) {
case PUBLIC:
return true;
case PROTECTED:
case DEFAULT:
return MoreElements.getPackage(target).equals(from);
case PRIVATE:
return false;
default:
throw new AssertionError();
}
}
public static boolean isVisibleFromSubclass(Element target, PackageElement from) {
switch (Visibility.effectiveVisibilityOfElement(target)) {
case PUBLIC:
case PROTECTED:
return true;
case DEFAULT:
return MoreElements.getPackage(target).equals(from);
case PRIVATE:
return false;
default:
throw new AssertionError();
}
}Then the special cases for |
kluever
added
type=addition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A useful addition to
MoreElementsorVisibilitycould be a way to check whether a givenElementcan see another one; the expected most-common use-case being to check whether some method can be called from another class (particularly when enumerating methods of a class including inherited methods from class hierarchy). The method would returnfalseif the target element isprivate,trueif it'spublic(and all enclosing elements are also visible to the source element; i.e. if the effective visibility of the element ispublic), and would check whether the source and target elements are in the same package otherwise.For example, in Bullet•, the generated class will call methods from the processed Dagger‡ component. Components can be abstract classes and therefore inherit methods from a base class. The Bullet• processor thus needs to check which methods the generated class will be able to call without causing a compilation error, and similarly for types for member injections (either to avoid generating such code, or to possibly generate helper code in the appropriate package, to get access to the type or method).
The API could look like:
or
In the case of Bullet•, the from will likely be the package (as a
PackageElement) where the class is being generated.When generating a subclass, one could want to know which methods from the parent class are callable from the subclass, so there could be an option to get a
truewhen the target field or method (or nested type) isprotected, even if not in the same package. Not sure what the API would look like though.FWIW, GWT's
JClassTypehasgetInheritableMethodsfor methods a subclass could call, andgetOverridableMethodsfor those you can override in a subclass (that would be the subset of inheritable methods that's notfinal). And there actually is a TODO in the code to add anisCallable: https://github.com/gwtproject/gwt/blob/a6da588fadc17f9ae5b77204d25bad70f3846e4f/user/src/com/google/gwt/place/rebind/PlaceHistoryGeneratorContext.java#L288-L290 But while GWT limits it to methods, this is applicable to fields, nested types, and types in general (e.g. when looking at return types or parameter types of methods, or types of fields: not only the method or field needs to be accessible, but also the referenced type(s)).The text was updated successfully, but these errors were encountered: