8000 `clippy::same_name_method` with Stylize · Issue #1141 · ratatui/ratatui · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

clippy::same_name_method with Stylize #1141

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

Open
EdJoPaTo opened this issue May 25, 2024 · 5 comments
Open

clippy::same_name_method with Stylize #1141

EdJoPaTo opened this issue May 25, 2024 · 5 comments
Labels
Status: Controversial There is some discussion about whether this is the right direction. Clarify and seek consensus. Status: Design Needed An issue that isn't yet designed or specified well enough to implement Type: Breaking Change This change will cause application code to break and must be noted in the breaking changes docs etc. Type: Enhancement New feature or request

Comments

@EdJoPaTo
Copy link
Contributor

Problem

Stylize introduces style and set_style. They are also implemented manually too.
clippy::same_name_method notices this.

Solution

Probably remove the manually implemented methods and only use the ones implemented on Stylize.
This will be a breaking change as the trait needs to be imported then.

@joshka
Copy link
Member
joshka commented May 27, 2024

The problem is the styled trait is much newer than all the ratatui apps in existence. This would break every file that has ratatui code in every one of them as they'd have to change every call to .style() to .set_style() and add the trait. The size of this break is too large to consider as being a reasonable thing even with deprecation and such.

@joshka joshka added Type: Enhancement Type: Enhancement New feature or request Type: Breaking Change This change will cause application code to break and must be noted in the breaking changes docs etc. Status: Design Needed An issue that isn't yet designed or specified well enough to implement and removed Type: Enhancement New feature or request Type: zEnhancement labels Jun 19, 2024
@joshka
Copy link
Member
joshka commented Jun 19, 2024

To move this ahead, I'd suggest thinking through the impact of this change on downstream code. It would be useful to consider the specific magnitude (how much will be affected) and effort involved in updating the code (i.e. specifically what would the compiler do, what find and replace would help, etc.). I've assumed above that these are likely too large to consider, and this might be correct, but perhaps there's an incremental approach that I'm missing here.

It might also be worth thinking about possible alternatives to this. Something that I've been thinking about is whether it's worth implementing the stylize methods directly on widgets using either declarative or derive macros rather than a blanket trait implementation. There are likely downsides to this approach too.

@joshka joshka added the Status: Controversial There is some discussion about whether this is the right direction. Clarify and seek consensus. label Jun 19, 2024
@EdJoPaTo
Copy link
Contributor Author

Macros would be neat as that can result in const methods then. As styles are done many times per render that could be a performance benefit on runtime, but comes at a compile time cost of these macros and their own complexity of writing / maintaining them. I don't think that its worth the effort here.

rust-analyzer should suggest importing traits for used methods so writing them newly shouldn't be a big problem for people using rust-analyzer. Migrating from direct impl to trait seems like a rather simple change, just add the import. Noting that in the breaking changes section should be easy to adapt to. Also, the Rust error output suggests importing the trait too if I remember correctly. Should be checked.

@joshka
Copy link
Member
joshka commented Jun 20, 2024

Macros would be neat as that can result in const methods then. As styles are done many times per render that could be a performance benefit on runtime, but comes at a compile time cost of these macros and their own complexity of writing / maintaining them. I don't think that its worth the effort here.

I'd be surprised if the performance gains / losses mentioned are meaningful in any reasonable use case.

We use macros for the colors and modifiers already, so the maintenance burden isn't high, and the existing implementation is simple and clear on this already. Maintenance burden would be unchanged.

rust-analyzer should suggest importing traits for used methods so writing them newly shouldn't be a big problem for people using rust-analyzer.

New users regularly have issues copying code and where trait imports are necessary.

Migrating from direct impl to trait seems like a rather simple change, just add the import. Noting that in the breaking changes section should be easy to adapt to. Also, the Rust error output suggests importing the trait too if I remember correctly. Should be checked.

The quantity of affected code is relevant here. When you change something that effects every single application built with ratatui like this, think of the time necessary to understand, read, fix, commit, review, and deploy this change for every app.

@EdJoPaTo EdJoPaTo removed their assignment Jun 20, 2024
@joshka
Copy link
Member
joshka commented Jun 21, 2024

I'd be surprised if the performance gains / losses mentioned are meaningful in any reasonable use case.

Confirmed there is no meaningful difference:

  • 0.32s vs 0.31s compile time in a synthetic test of macro vs no macro.
  • Single digit pico-seconds difference between benchmarks of trait impl, manual const function, macro generated const function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Controversial There is some discussion about whether this is the right direction. Clarify and seek consensus. Status: Design Needed An issue that isn't yet designed or specified well enough to implement Type: Breaking Change This change will cause application code to break and must be noted in the breaking changes docs etc. Type: Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants
0