-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Inheritance in natspec (documentation) #8911
Comments
Firstly, it's not mentioned in the docs how inherited (implemented) members would contain the NatSpec from base. Perhaps we should add this under the section "Inheritance Notes." For Q2.
With this rule, I don't see any problem with such a feature for interfaces. Also, why do we have to restrict this for only interfaces? Contracts can also have this. |
Oh, you mention https://solidity.readthedocs.io/en/v0.6.7/natspec-format.html#inheritance-notes with inheritance notes. |
We looked into that in the past, but I think doxygen and javadoc do not mention this subject, unfortunately. I would prefer to have an all-or-nothing behaviour: As soon as you provide a docstring, the base docstring is ignored. The same should happen for a function overriding multiple base functions, even if only one of them specfies docstrings. In addition to that, we could add |
In the docs for OpenZeppelin Contracts we manually add a reference to the overriden function. We plan to eventually also embed along with the link a portion of the referenced docs so the user doesn't have to click through so many links to see what is conceptually a single piece of information. It would probably be the first sentence, or maybe a few sentences up to some other delimiter. We would not expect any of this to be done automatically by the compiler, but we would be interested in some help from the compiler. For example, I don't think the AST currently has a reference to the function that is being overriden, so we don't have a way of automating the "See |
I see now that the |
@axic I think this is a really good idea. I could imagine that, if the implementing functions have different natspec tags, that the defined tags will override the content defined by the base classes, but the rest will just be inherited. This may improve the reusability. I also agree with @hrkrshnn that this may also be useful for contracts. |
On today's meeting we've agreed to the following:
|
I wonder if the given rules might be too intransparent for the end user |
One issue with |
I think we should also not inherit the documentation if one of the parameters or return parameters are named differently than in the base function. |
Regarding point 2, conflicting definitions. Is there mere presence of multiple bases enough to trigger this, or do they also need to have documentation?
Would we have a conflict already? |
Default inheritance of events does not seem to be working with #9267. |
natspec inheritance with events doesn't work because we never fill their "baseFunctions" variable in the callableannotation |
Inheritance is an untouched subject on Natspec -- I haven't found any issue regarding it.
Take this example:
This currently generates no user/devdoc on
Token
:Q1. It would be nice to have interfaces documented and transfer that over to the function in the documentation. Is that a bad idea?
Q2. What happens if the implementing function has a different
notice
orparam
. Does it take precedence? Is it ignored? Does it only take precedence over implementing an interface or applies to inheriting from contracts?The text was updated successfully, but these errors were encountered: