Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Swap priority order of bools/strings if strictBooleans is on #6044

Merged
merged 5 commits into from
Jun 5, 2023

Conversation

haltman-at
Copy link
Contributor

Addresses #6028.

The point of this is that, if there's an overloaded function with a bool overload and a string overload, then truffle call Contract f true ought to hit the bool overload, not the string overload. Of course this only makes sense if we're restricted to string input, which is more or less what the strictBooleans flag means.

I added tests also. You could also test it manually by making a function with a string overload and a bool overload and try calling it with truffle call.

Arguably this is a breaking change (to codec and encoder), but I'd consider it a bug fix. Overload resolution is never guaranteed anyway! :)

@haltman-at
Copy link
Contributor Author

Oh wait, I should update the docs in this PR as well... will have to go back and add that...

@haltman-at
Copy link
Contributor Author

OK, updated this with documentation!

Copy link
Contributor

@gnidan gnidan left a comment

Choose a reason for hiding this comment

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

Couple things I noticed (I won't request changes because I might not be around to dismiss the review for the next couple days)

@@ -10,6 10,7 @@ import { maxValue, minValue, places } from "./utils";
export function isMoreSpecificMultiple(
types1: Format.Types.OptionallyNamedType[],
types2: Format.Types.OptionallyNamedType[],
strictBooleans: boolean,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should be in an options style argument

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It could be if you really want, but this is sufficiently internal that I'm not really worried about that sort of thing -- there isn't a need to maintain a stable interface here, we can just change it as needed. Adding yet another options here seems more confusing than just adding a flag.

Copy link
Contributor

Choose a reason for hiding this comment

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

I really think we should always lean in favor of options-style arguments, but I won't press the issue here

Comment on lines 65 to 66
typeClasses.pop();
typeClasses.pop();
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks brittle; can we do it another way?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, there's any number of alternative ways to do it, the question is what's good without being too repetitive. I guess we could have everything but the last two, then tack on the last two depending on the flag? Would that be less brittle?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(I've made this change, let me know if you think a different way would be better.)

@eggplantzzz eggplantzzz self-requested a review June 5, 2023 19:27
Copy link
Contributor

@gnidan gnidan left a comment

Choose a reason for hiding this comment

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

Looks good!

@haltman-at haltman-at merged commit e044a7d into develop Jun 5, 2023
10 checks passed
@haltman-at haltman-at deleted the true-true branch June 5, 2023 19:46
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants