I’ve seen a couple references lately to using lazy attributes as a form of caching. This is a great approach to thinking about lazy attributes, as they share a number of characteristics with traditional caching: you only have to build a (potentially) expensive value once, and then only when you actually need it. But what about when that lazily generated value is too old to trust? A lazy attribute isn’t going to help you much then, as your instance is quite happy to keep on returning the same value forever once it has been built, unless you clear or change it manually.

One thing that that had been particularly annoying me lately, was the ridiculously long package names called for in a certain project of mine. The package names themselves weren’t the problem, it was writing them out. With filenames like lib/App/MediaTracker/TemplateFor/Browser/PrivatePath/libraries/things/document.pm, the corresponding package names become very long and very painful very quickly. Fortunately, I use vim as my editor of choice. Along with the fantastic snipmate vim plugin vim plugin it is possible to create a snippet that runs a little vim code as part of it:

Lazy attributes are wonderful. They allow us to postpone generating attribute values for any number of reasons: it’s expensive and we don’t want to do it unless we need it, it should be initialized after instantiation because it depends on other attributes, etc. And it does this without our having to worry about the value being around: if we need it, it’ll be generated on the fly without any extra effort on our part.

A while back, I wrote about “useful git defaults”. This is a tricky subject, as a sufficiently aged ~/.gitconfig is much like a vimrc or Chief O’Brien’s rank: a very religious topic. Nonetheless, it’s one of those things where a few small adjustments to the system-wide git configuration (a la /etc/gitconfig) can make things much, much easier — particularly in the case where there are multiple systems to manage, and multiple people using them.