-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Correctly tracking inventory changes to the cached inventory #3860
Correctly tracking inventory changes to the cached inventory #3860
Conversation
Updating fork
…ems, not pokemon) inventory
…ature/track-inventory
…o PokemonGoF-dev
Updating fork
…ature/track-inventory
Changed how to request an item recycling
@BriceSD, thanks for your PR! By analyzing the annotation information on this pull request, we identified @amal, @douglascamata and @TheSavior to be potential reviewers |
Can you solve merge conflicts, please? |
@douglascamata We should think about it more before merging imo. Having methods with same names but only some of them calling the api will confuse everyone. |
@BriceSD show me the code. |
@k4n30 They don’t have the same purpose |
close since no activity in 9 days/ |
NOT INTENDED TO BE MERGED AS IT IS
I’ve made these changes from the wrong branch, only look at item_recycle_worker.py, inventory.py and recycle_items.py
Description:
With the new cached inventory becoming a core component, we can’t afford to not correctly update it after every change.
I’ve made a class (RecycleWorker) which is more or less an api wrapper.
At first I put in it the responsibility to update the inventory. While not being bad, i feel like it’s easy to misunderstand what item.remove(amount) do. Namely removing the amount from the cached inventory without making a recycling request to the server.
What I’m proposing now to recycle an item is to use item.recycle(amount). Inside this method we’re doing a call to the api and then, depending on the success of the recycle request, we’re updating the cached inventory. By doing this we’ll never change the quantity of an item from outside the class. Thus we could allow only access to Item’s attribute and deny any change from the outside. This would make the cached inventory trustable.
However this could result in a very coupled code.
Having a class that adds a level of abstraction (RecycleWorker here) seems good enough though. The item know nothing about the recycling process. Not even how is defined a succeeding call.
I haven’t work much with the the pokemon inventory, or the pokemon catcher either. Not sure if throwing a ball during an encounter from the inventory is a good idea.
Any thoughts on the subject would be highly appreciate.
edit : @amal, @douglascamata, @TheSavior, @aeckert