I think getOrSet is catchy(), I don’t want to modify the get() as it will modify the interface and this is extra functionality a provider can implement or not.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com (http://www.ortussolutions.com/)
P/F: 1-888-557-8057
Direct: (909) 248-3408

ColdBox Platform: http://www.coldbox.org (http://www.coldbox.org/)
ContentBox Platform: http://www.gocontentbox.org (http://www.gocontentbox.org/)
Linked In: http://www.linkedin.com/pub/3/731/483

Social: twitter.com/ortussolutions (http://twitter.com/ortussolutions) | twitter.com/coldbox (http://twitter.com/coldbox) | twitter.com/lmajano (http://twitter.com/lmajano) | twitter.com/gocontentbox (http://twitter.com/gocontentbox)

Would it be possible to actually just override the regular get() method so you could pass in the closure necessary to create and set the data if it didn't exist?

The only issue I can think of with getOrSet() is that it implies only one of those operations will happen, and technically I supposed that might be true, but from the outside perspective of the method, it can set AND return the data. What about setAndGet()? Hmm, I don't really like that one either. We could call it something like guaranteedGet() other than the fact that's way to long and hard to spell

Brad, how about a method name called getOrSet()

Yes, I'm aware that the code sample has a potential race condition. I thought about it when I write it, but it was orthogonal to the point since I was just trying get the idea across so I left it. I'll update it so it's not confusing.

Regarding the memory issues-- I don't think we're on the same page. Firstly, I'm not suggesting we persist the closure anywhere-- it is only passed along to be executed if the item is not found in the cache. After the method is finished executing, the closure would be destroyed and not persisted anywhere. The vision was not that this method would be a "one time" thing you would call and then you would only need to do a get-- instead every call to the cache would pass along the closure, but the closure would only be used if the item didn't exist in the cache on that call.

That means There is no inherent memory leak potential. Whether or not the code is executed in its original environment or inside a closure should have no impact on memory.

Few comments.

Passing a closure is a nice idea but the issue is memory leaks. Closures will bring with them their entire environment scope. So if I cache the closure alongside the key in the provider so I can do callbacks, then I am caching everything the closure's environment is coming from. So in theory it is a good idea, but not a memory sensitive one. So I feel maybe registering a simple callback could be an alternative.

Second.
The code below is not good:

Because of the lookup. The cache cannot guarantee the results after the lookup. For best practices, you have to retrieve and validate.