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 :)
In reply to Re^2: RFC: Object::Proxy (or somesuch)
by stvn
in thread RFC: Object::Proxy (or somesuch)
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |