Hacker News Reader

Comment by antihero | Hacker News Reader

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 :)

View on HN

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.

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.

Yep, but i you can call "loosing the scope" as "specifying data dependencies explicitly" :) It all depends on a use case, though.

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.

I suppose I could use $var === False, to prevent it pick up empty results.

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

Reply on news.ycombinator.com