What about Object::Realize::Later, Class::LazyObject, or Data::Lazy? How would your module differ?

Data::Lazy seems to be only for variables, this module would be for objects.

With Class::LazyObject and Object::Realize::Later you seem to be required to create a ::Lazy package of some kind, which later on would turn into a non-lazy version of itself. For my needs at least, this was too much overhead.

How is this laziness effected anyhow? Is it going to make map Foo::Bar->new( foo => $_ ), LIST slimmer where Foo::Bar::new is something simple like return bless { @_ }, $class?

I doubt you will get much gains in efficiency from simple constructors, but then why would you want to lazy load it anyway? The real goal (at least for me, I cannot speak for dragonchild) is the ability to have an object, which looks like a Duck, and quacks like a Duck, but is only really a Duck at the very last possible second.

If you name your module after a proxy then I'd expect it to be something SOAP-like - your object stays around to relay stuff to and from the actual object which exists somewhere else. So don't use the term 'proxy' if the idea is about having something be lazy.

I disagree that proxy == SOAP-esque. The Proxy pattern is from the GoF Design Patterns book, and is just simply what you describe without the distributed part. I agree that proxy is not a good name, hence the reason for this meditation, we can't figure out a better one :)

Could you make this more general so you could make lazy expressions? So instead of getting a number back from 0 + $foo->bar you get back a value which will defer running ->bar until it is actually needed? Sort of like promises from E.

Maybe you could just name your module Object::Realize::Later::Lighter if the improvement is that you avoid having a ::Lazy package. Are you really proposing having so many lazy packages that avoiding adding a ::Lazy one is going to help? Partially I wonder because AFAICT, Object::Realize::Later is already sort of a standard when people solve this problem.

In reading the docs for O::R::L, I was put off by the amount of book-keeping I, as the programmer, needed to do. Plus, I couldn't lazyload a class that didn't already have a bunch of crap defined for it. It also seems like so much overhead just to
1. intercept the constructor call
2. intercept the first usage
3. get the heck out of the way
What about calling it Class::Plugin::LazyLoad? That's actually the exact term for what it's doing, now that I think about it.

As for deferring expressions, I can look at that. It wouldn't be in this module, though. That would be more of Expression::Plugin::LazyLoad ... or somesuch.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Could you make this more general so you could make lazy expressions? So instead of getting a number back from 0 + $foo->bar you get back a value which will defer running ->bar until it is actually needed? Sort of like promises from E.

I dont think that would be possible due to the way that perl evaulates arguments.

Maybe you could just name your module Object::Realize::Later::Lighter if the improvement is that you avoid having a ::Lazy package.

Well, we also add a number of other features, including; handling overloaded ops, and handling direct access ($obj->{field} but not just hashs. Blessed arrays,scalars and subs as well.). In general the API and style is very different than Object::Realize::Later so I dont think it would fit.

-stvn

We differ from Data::Lazy because we're not tied and we're not specific to data structure. We're specific to classes and objects.

The laziness is effected by substituting a lazy constructor for the real constructor(s). Our constructor is sub new { bless @_ }. (No, we don't expect to be inherited from.) Then, when any method is called or any direct access is attempted or any overloaded operator is used, we build the object, then redispatch the requested access/method/overload.

So, the benefits are that we defer all construction until such a time as you absolutely need the object. Potentially, if you don't use the object, it never gets constructed. There is a slight penalty for the first access to the object, but it's very slight (almost negligible).

I think the word Proxy goes away in favor of LazyLoad. Better?