-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Question: Warnings raised when there are Events with the same name but different inputs? #905
Comments
The main reason is because of how you would access them. If you have a single Many of these issues go away in v6 which will use a Proxy, but for now this is something there isn't a great way around. You can always lower the Logger logLevel to |
I think this has been answered, so I'm going to close it. If you still have further questions though, please feel free to re-open. Thanks! :) |
Hi, ricmoo. |
@ricmoo However the exact problem occurs with overloaded function names, and ethers does not report a warning when there are overloaded functions -- you have to just manually call overloaded functions using a dict lookup rather than accessing a |
@ricmoo Another problem with this warning is that the warning is issued even when a user is not subscribed to monitor the event in question. |
@lukehutch Because v5 aims to be ES3 compatible, there is no useful way at runtime to issue that warning in a way that doesn’t result in uncallable methods with no feedback. It does behave identically for both functions and events in v5; overloaded methods and events must be specified by their normalized signature, or the unnecessary fragments dropped from the ABI. I personally recommend dropping unnecessary fragments, as it makes the code far more readable, and shrinks the size of the app by removing descriptors that are never used (and cannot be pruned by tree-shaking). That said, this is no longer an issue in v6, as it can use ES5 Proxy, which provides a runtime error if something is misused, and also the Typed API to make code far more readable in the case of overloaded features. :) |
@ricmoo but I get this warning on ethers v5 even if I'm not listening to the |
@lukehutch But that cannot be done without Proxy. Because there is no way to detect it is being used. Imagine With ES3 features, there is no way to really do this if a way without breaking other parts and uses of the libraries (e.g. using deferred errors, which break enumeration). |
I guess this is the question: how would ethers know whether you care about it or not? The best way would be to not include them in the ABI. But there isn’t much that can be done otherwise. (Proxy makes this all go away ;)) |
@ricmoo I don't understand what you mean about Proxy, sorry -- but I assume you're saying that once ethers v6 is released, I can just upgrade to that version and the warning will go away? |
@lukehutch Without the ES5 Proxy, there is no way to detect whether something is used or not, which is why v5 must assume it is used. Yes, there is no warning in v6, but it is still very beta. :) |
Well could you please at least create a setting for disabling this warning on ES3? The user should be able to decide whether they care about it or not. I have hundreds of lines of this warning in my test output, and that obscures legitimate test output. |
@lukehutch
at the beginning of the helpers.js lib that I import in any test. |
Given the following ABI with two
Transfer
events with different inputs:In contract form this would look like:
When calling the above contract,
[email protected]
logs the following warning:Why do we warn users for having Events with duplicate names? I would expect that the intention is to check for duplicate Event signatures, for example:
Transfer(address,address,uint256,bytes)
,Transfer(address,address,uint256)
] is OK 👍 since they have different event signatures.Transfer(address,address,uint256,bytes)
,Transfer(address,address,uint256,bytes)
] is NOT OK 👎because they have duplicate event signatures.
Is this because of the events API expecting an event name?
The text was updated successfully, but these errors were encountered: