Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Javadoc of predicates and functions #912

Merged
merged 5 commits into from
Jul 13, 2022
Merged

Conversation

codecholeric
Copy link
Collaborator

At the moment it is quite challenging to find a certain predicate or function, because users might need to know the domain model very well to find the necessary location (e.g. predicates like nameMatching(..) are defined within HasName.Predicates to be reused for everything that has a name, but at the same time users now need to know that JavaClass implements HasName to use these predicates).

While in the long term it might make sense to implement a better entry point API to improve discoverability, for now we can at least improve the documentation to link from more specific predicates to more generic ones. I.e. that I have some chance to discover

  1. Javadoc on some method ...That(DescribedPredicate<? super JavaClass>) -> "you can find predefined predicates in JavaClass.Predicates
  2. Javadoc on JavaClass.Predicates -> "due to inheritance you can find further applicable predicates in HasName.Predicates, HasModifiers.Predicates, ..."

The type bounds were too limiting. If we want to restrict to `onlyBeCalledByMethodsThat(predicate)`, then we should support a `DescribedPredicate<T>` up to `T` being `JavaMethod` and not just `JavaMember`. Otherwise, it is impossible to assert things like `onlyBeCalledByMethodsThat(haveRawParameterTypes(..))`, because `haveRawParameterTypes(..)` is a predicate on `JavaCodeUnit` and not `JavaMember`.

Signed-off-by: Peter Gafert <[email protected]>
Copy link
Member

@hankem hankem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duly noted that many predefined predicates can be found within a subclass Predicates of the respective domain object or a common ancestor. 😂 SCNR

Wow, that was a lot of work, but it might probably help the users a lot!
(Let's hope that we'll keep this consistent in the future... 🙈)

I've just left some wording suggestions; they probably won't make much difference, just pick whatever you prefer.

@codecholeric
Copy link
Collaborator Author

Thanks so much for the extensive review!! 😄 I know that it is a lot of repetition and I also worry about keeping it consistent in the future. But I see no other choice, because you don't know from where users enter the API 🤷‍♂️ And the benefit of having this in many places IMHO outweighs if it should be inconsistent in some place in the future...

In particular, users were confused about the semantics of joining multiple `andShould()` and `orShould()`. It is not self-evident that there is no operator precedence as developers are used to from `&&` and `||`. We should make sure that every conjunction at least links to some documentation that explains the associativity of joining multiple parts, as well as the alternative by directly supplying predicates/conditions that can be freely nested and joined via `and(..)` and `or(..)`.

Signed-off-by: Peter Gafert <[email protected]>
At the moment it is quite challenging to find a certain `DescribedPredicate`, because users might need to know the domain model very well to find the necessary location. While, in the long run we might offer a better entry point into the API that improves discoverability of predicates, as a slight improvement we add javadoc to all predicates linking to respective other predicates that can also be applied to the object. E.g. while before users might be confused why `JavaClass.Predicates` has no predicate defined for `JavaClass.name` now there is at least a link that further predicates that can be applied to `JavaClass` due to inheritance can be found in `HasName.Predicates`.

Signed-off-by: Peter Gafert <[email protected]>
Same as for predicates at the moment it is quite challenging to find a certain `ChainableFunction` for a specific domain object. Thus, we should also link to other function declarations where it makes sense.

Signed-off-by: Peter Gafert <[email protected]>
@codecholeric codecholeric merged commit b3a47b5 into main Jul 13, 2022
@codecholeric codecholeric deleted the improve-javadoc branch July 13, 2022 07:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants