On Thu, 9 Mar 2023 20:06:53 GMT, Jonathan Gibbons <[email protected]> wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to feedback > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java > line 647: > >> 645: } >> 646: >> 647: private boolean allowInheritedMethod(ExecutableElement >> inheritedMethod, > > what does `allow` mean in this context? if it's inherited, doesn't that mean > it's allowed? how can an inherited method not be allowed? While I agree that _allow_ seems strange here, it was here before and it is consistent with other methods, such as `allowInheritedMembers` (note "Members", not "Methods"). Not being a native English speaker, I could imagine that here "allow" means "to let inside", "enter" ( see https://idioms.thefreedictionary.com/allow+somebody+into ). That method is used as a predicate for filtering. It allows some method elements inside a list. This would be my best guess. Anyhow, I suggest that we deal with that name later; there's a bigger issue with that method: while it's a predicate, it has side effects, such as modifications to `overriddenMethodTable`. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java > line 699: > >> 697: ExecutableElement lMethod = (ExecutableElement) le; >> 698: // Ignore private methods or those methods marked with >> 699: // a "hidden" tag. // FIXME I cannot see where @hidden is >> ignored > > Generally, there is `utils.hasHiddenTag` > > It _may_ be a good design question as to when `@hidden` should be taken into > account. For example, should VMT build an accurate model and only suppress > on output, or should `@hidden` be reflected in the VMT model. > > If it helps (?) I note that at one time a precursor of `@hidden` was > `@treatAsPrivate` Can we leave it for the next round? ------------- PR: https://git.openjdk.org/jdk/pull/12887
