Now, the average user of this screen will look at 2-3 invoices. Why should I pre-load 25-35 invoices, with some 50-70 DB queries, when I can defer loading until the user actually tells me which one they care about?

Now, so far, you say "Just use another screen." But, I didn't write the Invoice object code. I am told I have to reuse code because my PHB needs to look good, but I am not allowed to modify it because my PHB has no clout.

Enter Class::LazyLoad. The Invoice object doesn't even know it's being deferred, nor does it care. The Customer screen now loads really fast and all the information that used to be there still is.

This is the kind of thing that Class::DBI does for me automatically, but that doesn't help you since this is someone else's code. After taking a brief glance at Class::LazyObject though, I think that it would do what you want without additional effort. There is also Class::Proxy and Class::Proxy::Lite, but the docs for those are a bit harder to follow.

Let me just say:

kewl!

/J

The point of being able to lazyload just a single instance is basically to be as unintrusive as possible, while still allowing this to be possible. Let me explain in more detail.

Say you want to lazy load ever instance of the class.

use Class::LazyLoader 'My::Class'; 

push @lazy_classes => My::Class->new() for 1 .. 100;
[download]

Now take this particular example (based on the IOC issues mentioned above in response to dio).

My A constructor requires an instance of B, and my B constructor requires an instance of A. The best solution is to give A a real B instance, and give B a lazy-loaded A instance.

Now say my C constructor requires an instance of A. I previously gave B a lazy-loaded A, however, there is no need to give C a lazy-loaded A, that is an unessecary level of indirection. But if lazy-loading was on a class level only, I would not be able to make this choice. With lazy-loading being available on a per-instance basis I can give C a real A instance.

Of course the need (or desire) to fiddle at this low a level is a rare instance and one not likely to be an issue for anyone but me. However, this is exactly the issue that caused dragonchild and I to start talking about and building this module.