Simplify implementation of item equality #87
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in #82, the current implementation seems non-ideal because it, intentionally or not, compares item paths and fetches their attributes at the same time once the paths are equal. Since all the fetching is done "just in time" and not from previously cached value on
Item
, these calls would always return the same attributes since the paths are also the same.As this behavior has been in
master
for years now (seemingly without issue), it seems unlikely that anyone has run into the case where the path changes silently due to a provider change while anItem
object is alive. If someone raises this issue later it can be evaluated then and fixed whenever the next major release ofzbus
comes out to accompany the breaking change required.Additionally this PR takes advantage of the fact that the async
Item
implementation no longer needs to make calls via.await
and implementsPartialEq
for the item instead to more closely match theblocking
Item
public API.Closes #82