a contract of the cache is that
if cache.put(k,v); then v.equals(cache.get(k)) or v is null
so if you just created v and put it into cache, why also introduce the
overhead of the lookup?
this style of code also has a single return point:
V v=cache.get(k);
if (v==null) {
v=new V();
cache.put(k,v);
}
return v;
its just coding preference, we seem to like the example above more.
-igor
On Feb 13, 2008 1:39 AM, Ned Collyer <[EMAIL PROTECTED]> wrote:
>
> I've been digging around in some of the code and its great :) I really like
> the design choices of wicket.
>
> One thing that I've stumbled on a couple of times is the use of cache - Eg,
> PropertiesFactory
>
> I've previously used caching like this
>
>
> if (!cache.containsKey(whateverKey)) {
> cache.put(whateverKey, object)
> }
>
> return cache.get(whateverKey)
>
>
> Its a very similar approach but perhaps simpler. I guess the point here is
> that I always try to get something out of the cache rather than something
> I've loaded during the method. There is a single point for returning the
> object.
>
> Anyway, just something to think about.. perhaps. (or i miss something). I
> don't profess to know what I'm talking about.
>
> Thanks for making such a great framework.
> --
> View this message in context:
> http://www.nabble.com/Ideas-on-cache-tp15452545p15452545.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
