3 ms·

Thanks, and I agree. I usually use exceptions but for some things (like cache misses) it seems unwieldy. For the example of the cache calls, I check when I've d

Thanks, and I agree. I usually use exceptions but for some things (like cache misses) it seems unwieldy. For the example of the cache calls, I check when I've done a cache call like: $data = $cache->get("key"); if(!$data) { // do the stuff if cache misses } Though yes, I do need to go through and make sure it's extremely robust, as I did hack it up in an evening :)

shepik 15y ago
Y U NO USE your cache like that: $data = $cache->get('key',function() { // do the stuff if cache misses return $some_value_to_be_cached; }); ? It's quite handy and it forces you to separate actual logic to get the value, which is good by itself.
- antihero 15y ago
  That's a cool idea, but I wouldn't want to lose the scope as you would with a closure. I will look into seeing if it's possible, though.
  - shepik 15y ago
    Yep, but i you can call "loosing the scope" as "specifying data dependencies explicitly" :) It all depends on a use case, though.
  - gordonslondon 15y ago
    That not just a cool idea, that's essential to a cache system. What if you want store FALSE in your cache? You will get a miss everytime your cache key is accessed.
hendrik-xdest 15y ago
I was thinking about the part where you check the cache with if (!$found) On that note, I adapted a rule of an open source project (can't quite remember which) that said to never use !$var to validate your data. One should always use isset($found['args']) or empty($found['args']) or for example is_array($found) && count($found) > 0 to check.
- antihero 15y ago
  I suppose I could use $var === False, to prevent it pick up empty results.
- Gigablah 15y ago
  I've been burnt by this in the past. Nowadays I use ($found === false) to check for a cache miss (though this means you can't store boolean values verbatim). This is why: !array() -> true !null -> true !false -> true !0 -> true !"0" -> true (!!?) !"" -> true

shepik 15y ago

Y U NO USE your cache like that: $data = $cache->get('key',function() { // do the stuff if cache misses return $some_value_to_be_cached; }); ? It's quite handy and it forces you to separate actual logic to get the value, which is good by itself.

antihero 15y ago
That's a cool idea, but I wouldn't want to lose the scope as you would with a closure. I will look into seeing if it's possible, though.
- shepik 15y ago
  Yep, but i you can call "loosing the scope" as "specifying data dependencies explicitly" :) It all depends on a use case, though.
- gordonslondon 15y ago
  That not just a cool idea, that's essential to a cache system. What if you want store FALSE in your cache? You will get a miss everytime your cache key is accessed.

hendrik-xdest 15y ago

I was thinking about the part where you check the cache with if (!$found) On that note, I adapted a rule of an open source project (can't quite remember which) that said to never use !$var to validate your data. One should always use isset($found['args']) or empty($found['args']) or for example is_array($found) && count($found) > 0 to check.

antihero 15y ago
I suppose I could use $var === False, to prevent it pick up empty results.
Gigablah 15y ago
I've been burnt by this in the past. Nowadays I use ($found === false) to check for a cache miss (though this means you can't store boolean values verbatim). This is why: !array() -> true !null -> true !false -> true !0 -> true !"0" -> true (!!?) !"" -> true