Closed (fixed)
Project:
Services
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
6 Aug 2011 at 18:11 UTC
Updated:
16 Mar 2012 at 22:40 UTC
Jump to comment: Most recent file
Lets us drupal_static in function services_server_info_object() instead of d6 approach static. Also add functionality of $reset key.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | fast-static-2.patch | 614 bytes | marcingy |
| #11 | fast-static.patch | 649 bytes | marcingy |
| #4 | 0001-Add-rest-to-services_server_info_object.patch | 713 bytes | ygerasimov |
| services_server_info_object-drupal_static.patch | 926 bytes | ygerasimov |
Comments
Comment #1
marcingy commentedI wonder if we should infact use the fast static pattern here, given the number of times this function is called during the services processes.
Comment #2
ygerasimov commentedI think we should follow d7 pattern on this. Also $reset functionality is enabled with this patch.
Comment #3
marcingy commentedDrupal fast static is a drupal pattern see second example on this page http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal...
Comment #4
ygerasimov commentedAlright. Lets keep it $static as we are sure nobody will need to reset this cache from other places. Attached patch only adds usage of $reset key.
Comment #5
marcingy commentedWe want to do this
So we still have a drupal based static that can be reset from every plus the additional benefit of localised static.
Comment #6
ygerasimov commented@marcingy truly to say #5 looks more complicated that it is now. I wouldn't go for this way. Lets keep it simple whether using drupal_static() or simple static.
Lets just commit #4 adding $rest key and thats it.
Comment #7
marcingy commentedYes it is more complex but it also then allows the usage of drupal_static_reset and it is only more complex from an implemtation point of view and we only have to do it once. So lets do this properly.
Comment #8
kylebrowning commentedwhere we at with this?
Comment #9
kylebrowning commentedComment #10
ygerasimov commentedKyle, I think we should go forward on this with original patch. Simple changing to using drupal_static().
Comment #11
marcingy commentedFast static version
Comment #12
marcingy commentedComment #13
ygerasimov commentedNever seen such pattern.
Why do we need &drupal_static here as we overrite it with empty object on the next line?
Comment #14
marcingy commentedThe answer is we need a fast static the code may need work but original patch should not be committed is my point....and I rolled this patch despite being up since 6 am my time to prevent this happening due to the comment in #10 ie the original patch is wrong and have said this lots of times. But what ever commit what ever you want.....
Comment #15
marcingy commentedThe problem is that you can't provide a new class as a default value to drupal static, the former is creating a reference to the varaiable the latter is getting round the initialisation issue described above as you have to initialise to an array or string. If you can do the operations in one sure go for it. And if you grep drupal_static_fast you will find its usage in multiple places in core. The idea is that provides the benefits of a localised static along with the ability to perform a centralised reset.
Comment #16
kylebrowning commentedso whats going on with this?
Comment #17
marcingy commentedSo it turns out this funky approach does actually work, don't you love php at times!
Comment #18
kylebrowning commentedComment #19
marcingy commented