Have outer classes extend Recipe too #17
Conversation
Simplifies calling related recipes all together without Yaml recipe lists.
|
Possibly wr should actually declare the nested classes with the same visibility as in the Refaster source. That way a nested class can also be private and as a result only the outer recipe would be callable. I think that could be useful. |
Indeed a neat idea to match input and output modifiers for nested classes. Applied a first such change in 8b26e4c ; Not done for outer classes, as that would hide the inner ones as well I believe. |
|
|
||
| @Override | ||
| public String getDescription() { | ||
| return "Refaster template recipes for `foo.MultipleDereferences`."; |
There was a problem hiding this comment.
Should we possibly also here include the source code as Markdown?
There was a problem hiding this comment.
I'm afraid that would result in a very long blob of text for some of the recipes I anticipate here. Take for instance the Plexus StringUtils methods we hope to replace with recipes; that's a long list that I think would best be documented on each of the individual recipes.
I do understand there's some tension with whether that recipe would have visible individual recipes, but since we also plan to add a @DocumentExample to the docs, then I think including the recipe source here could be too much.
There was a problem hiding this comment.
OK. Let's keep it like this for now. We may want to add an annotation with which we can control the generation of the display name and description.
Simplifies calling related recipes all together without Yaml recipe lists.
I don't immediately see any possible negative effects: we already generate the class, and having a way to run all of them together should simplify things for the majority of cases.