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

Implement PartialEq for WeakRef #1006

Merged
merged 1 commit into from
Feb 17, 2023
Merged

Implement PartialEq for WeakRef #1006

merged 1 commit into from
Feb 17, 2023

Conversation

andy128k
Copy link
Contributor

Does it make sense?

Related to #39

Copy link
Member

@sdroege sdroege left a comment

Choose a reason for hiding this comment

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

I think that's OK, yes.

Why did you decide to not also implement Eq, PartialOrd, Ord and Hash though?

@andy128k
Copy link
Contributor Author

No specific reason. I was just focused on an implementation of WeakMap/WeakSet and needed PartialEq.

I've just added Eq and Hash. Not sure if Ord for pointers makes sense.

@sdroege
Copy link
Member

sdroege commented Feb 17, 2023

Hm thinking about it a bit more, it's a bit problematic that the pointer value can just change. So if you store this in a HashMap or BTreeMap its position can randomly change. OTOH that's also the case with RefCell (BTreeMap, it has an Ord impl) but that seems like a bug to me.

I think Hash is wrong and only PartialOrd, PartialEq are potentially OK. What do you think?

@andy128k
Copy link
Contributor Author

I don't use BTreeMap or HashMap but just a Vec<WeakRef<_>>, so I would be happy with sole PartialEq.

@andy128k
Copy link
Contributor Author

impl Hash is removed

@andy128k
Copy link
Contributor Author

I think PartialOrd/Ord could be confusing for someone ordering WeakRef<gtk::StringObject>.

@andy128k
Copy link
Contributor Author

I was looking how weak references are implemented in gobject and they seem pretty expensive (relatively).

I want to have something better than x.upgrade() == Some(y) and x.upgrade() == y.upgrade().

@sdroege
Copy link
Member

sdroege commented Feb 17, 2023

I think PartialOrd/Ord could be confusing for someone ordering WeakRef<gtk::StringObject>.

PartialOrd / Ord are implemented on StringObject though so that would only be consistent.

I was looking how weak references are implemented in gobject and they seem pretty expensive (relatively).

Yes


In summary, I think PartialOrd and PartialEq are fine but the others not.

@sdroege
Copy link
Member

sdroege commented Feb 17, 2023

In summary, I think PartialOrd and PartialEq are fine but the others not.

The others (that are not fine) include Ord and Eq if that was not clear. AFAIU their requirements are violated by the pointer possibly changing randomly.

sdroege
sdroege previously approved these changes Feb 17, 2023
@sdroege sdroege merged commit 713401d into gtk-rs:master Feb 17, 2023
@andy128k andy128k deleted the weakref-eq branch February 17, 2023 09:58
@sdroege
Copy link
Member

sdroege commented Feb 17, 2023

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f68c45adc9f9b1fe064be663807a1b2c FWIW for the problem I mentioned. Funny enough there is even a clippy lint warning about that: https://rust-lang.github.io/rust-clippy/master/index.html#mutable_key_type

@sdroege sdroege added the backported PR was backported to the current stable branch label Feb 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported PR was backported to the current stable branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants