Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Cache API: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
Line 8: Line 8:


3. I took the liberty of correcting one thing on [[Cache_API_-_Quick_reference]] to match [[Cache API]] (make -> make_with_params in Getting an ad-hoc cache instance section). However there are other things that need to be corrected that I am not sure about. I will leave them for you.
3. I took the liberty of correcting one thing on [[Cache_API_-_Quick_reference]] to match [[Cache API]] (make -> make_with_params in Getting an ad-hoc cache instance section). However there are other things that need to be corrected that I am not sure about. I will leave them for you.
:Thanks for looking over the doc Tim, in reply:
:# Returning in these methods was intentional albeit against the grain of our normal design. My thinking was that if we are going to be using this in areas such as strings and config we need to minimise or in this case mitigate the risk of having them fail. Strings for instance are particularly problematic as they are used within Exceptions themselves. At one point earlier on within my design I was throwing exceptions there, however it became nightmarish when I broken the store the string cache was using, those exceptions were triggered leading to strings to be requested triggering the exception again... ongoing mayhem.
:# After reading back through this doc I completely agree, perhaps make_ad_hoc. If we're going to refer to these caches as ad_hoc that would be the name that makes the most sense I think. Easy to refactor in code as there are not any uses yet. I'll make that change this morning.
:# Thanks! As always go nuts, I'll ask Helen to read over these docs when I'm complete as well, she's a saint and is great at cleaning up the docs, cleaning up the spelling blemishes and de-wording the overly wordy bits.
: Cheers, Sam 04:56, 31 August 2012 (WST)

Revision as of 20:56, 30 August 2012

Some comments

from Tim.

1. In the "Using your cache object" section, you have set and delete returning a status. Surely it is better to have them throw an exception on error, and just return on success (like the DB API).

2. make_with_params is not a great method name. Sadly, I can't do better. make_ad_hoc? make_one_off? make_custom?

3. I took the liberty of correcting one thing on Cache_API_-_Quick_reference to match Cache API (make -> make_with_params in Getting an ad-hoc cache instance section). However there are other things that need to be corrected that I am not sure about. I will leave them for you.

Thanks for looking over the doc Tim, in reply:
  1. Returning in these methods was intentional albeit against the grain of our normal design. My thinking was that if we are going to be using this in areas such as strings and config we need to minimise or in this case mitigate the risk of having them fail. Strings for instance are particularly problematic as they are used within Exceptions themselves. At one point earlier on within my design I was throwing exceptions there, however it became nightmarish when I broken the store the string cache was using, those exceptions were triggered leading to strings to be requested triggering the exception again... ongoing mayhem.
  2. After reading back through this doc I completely agree, perhaps make_ad_hoc. If we're going to refer to these caches as ad_hoc that would be the name that makes the most sense I think. Easy to refactor in code as there are not any uses yet. I'll make that change this morning.
  3. Thanks! As always go nuts, I'll ask Helen to read over these docs when I'm complete as well, she's a saint and is great at cleaning up the docs, cleaning up the spelling blemishes and de-wording the overly wordy bits.
Cheers, Sam 04:56, 31 August 2012 (WST)