Note:

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

Talk:Cache API

From MoodleDocs

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)
1. I can appreciate the problems of using this in low-level code. I had similar struggles with moodle_page and exceptions. However, should the API that all developers have to use be sucky just because one poor developer (you!) has to make some low-level code work? I don't think so. I suggest a better way to resolve this is the change the exception display code to use some special function (get_string_uncached?) and then make the cache API nice. I do not believe that displaying error pages is ever performance-critical.--Tim Hunt 05:30, 31 August 2012 (WST)