| 102 | ==== cboos' feedback ==== |
| 103 | It's really nice, I like it a lot! |
| 104 | |
| 105 | When reviewing the code, I think I've detected some possible issues in `CacheManager.get`. |
| 106 | - in case there are multiple "out-of-date" threads, each might trigger a retrieval. An improvement would be to check if the `CacheManager` already has a "newer" generation. |
| 107 | - in the locked section, if the generation increases after the cached value retrieval and before the fetch of the latest generation, the `CacheManager` may think it is up to date yet have old data. |
| 108 | Those are admittedly corner cases, I hope I have not missed more important issues while focusing on that ;-) See the first patch attachment:cache-manager_get-corner-cases.patch. |
| 109 | |
| 110 | Another little improvement I'd like to propose is to not have to bother with key names and let the decorators figure out the key from the method itself. See attachment:cache-manager-automatic-key.patch. |
| 111 | I've also added more documentation to the decorators and changed the order of the definitions in a top-down way (first the decorators, then the descriptors, ending with the proxy class), as I think it's easier to understand that way. |