-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
PSR-5 provide a way to indicate if a method result is cached or not #131
Comments
Note that this PSR is pretty much dead as of now. However, to reply to your actual request. This tag would, if it is even useful in a broader sense, need to be called @memoized because that is what it is about. That being said, the exposure of the place and/or technology that is actually taking care of the memoization results in leakage of an implementation detail that should be documented with other means. For example design documents. The problem with such tags is that they tend to get outdated too fast and their usefulness diminishes too fast. |
Thanks for the quick response and the precision!
If I understood well, considering instance properties, class properties or static variables it's memoization. For systems like memcache, Redis or local files, we're speacking about cache. I don't know if two different words would be better or not.
I totally agree with you but I'm currently working on an app that has been made four years ago by someone else without any technical document and I try to make it "more standard" and robust. As I start from almost nothing, beginning by comments is a far easier way to get an overview about it to be able to make technical documents in some time. Which mean you're theoretically 100% wright but factually more or less wrong when we speak about sold product which has a lot of value for it's customers and a lot (more than a lot actually :) ) of code debt.
I understand for the fact they get outdated quickly but not really for the usefulness. This kind of optimization can produce big loss of time when you code the tests (which is exactly what I'm doing these times) or during debug phases which make it extremely useful once the feature is implemented and is just a dependence of a new one. Anyway, as this PSR is dying, this is not really important but thanks again for the answer, hoping my point of view can show you an other insight. |
It sounds like your need is a temporary one, though a medium-term That said, I can suggest how I might use what's available in phpDocumentor The functions are not real... they are solely to be constructs for your The bonus is the opposite end of the "@uses" tag. By having it point to a I've used this technique to help highlight when a function/method is used Thanks for the quick response and the precision! if it is even useful in a broader sense, need to be called @memoized If I understood well, considering instance properties, class properties or That being said, the exposure of the place and/or technology that is I totally agree with you but I'm currently working on an app that has been Which mean you're theoretically 100% wright but factually more or less The problem with such tags is that they tend to get outdated too fast and I understand for the fact they get outdated quickly but not really for the Anyway, as this PSR is dying, this is not really important but thanks again — |
@ashnazg oO great approach! Thanks for the clear explanation! Let's close this issue. |
My main argument for I did not say that you might not have a special use case, however, it is a special use case and should be solved by a special solution. I would not go for the proposed
e.g. |
I work on a lot of models those times and realized it would be nice to be able to characterize methods by the fact their results are cached or not.
An @cached tag, maybe associated with the caching interface used.
For example :
@cached instance (If the result is stored in a property)
@cached class (If the cache is stored in a static property)
@cached (The name of the class making the interface with redis, memcache or whatever)
I've seen nothing proposing it so I hope this idea is not just totally dumb :)
The text was updated successfully, but these errors were encountered: