Skip to content
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

Use widget::Id directly instead of duplicated subclasses #2745

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kiilerix
Copy link

@kiilerix kiilerix commented Jan 23, 2025

There doesn't seem to be any benefit from encapsulating Id in widget specific types or to not allowing custom Ids for container and scrollable.

Keep the widget ::Id around as an alias for backwards compatibility and minimal diff.

There doesn't seem to be any benefit from encapsulating Id in widget
specific types or to not allowing custom Ids for container and
scrollable.

Keep the widget ::Id around as an alias for backwards compatibility and
minimal diff.
Copy link
Member

@hecrj hecrj left a comment

Choose a reason for hiding this comment

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

There is a reason for the different Id types. They increase the type-safety of specific widget operations. For instance, it should be impossible for you to try to scroll a container.

@hecrj hecrj closed this Jan 23, 2025
@hecrj hecrj added this to the 0.14 milestone Jan 23, 2025
@kiilerix
Copy link
Author

Ok, thanks for explaining the reason for keeping it as it is.

But since these IDs are very weak links that might get invalidated, and some of them can be constructed from any string, the different types doesn't seem to provide much guarantee of correctness. Especially since the underlying operations use plain IDs without any type safety. It thus seems like a non-trivial amount of code to duplicate for each widget type for little gain.

Anyway, #2653 thus seems to bring exactly the right amount of code duplication to give text_editor the same functionality as other widgets have.

@hecrj
Copy link
Member

hecrj commented Feb 4, 2025

Hmm... I think you have a point.

I'll think about it. Let's reopen this.

@hecrj hecrj reopened this Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants