Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: RFC - Class::LazyObject

by lachoy (Parson)
on Oct 08, 2003 at 03:34 UTC ( #297470=note: print w/replies, xml ) Need Help??

in reply to RFC - Class::LazyObject

I hate to be a stinker after you've put in what's obviously a good bit of work, but this appears to do pretty much the same thing as Object::Realize::Later. Is there a difference?

M-x auto-bs-mode

Replies are listed 'Best First'.
Re: Re: RFC - Class::LazyObject
by QwertyD (Pilgrim) on Oct 08, 2003 at 04:10 UTC

    *mumble grumble mumble*
    I searched CPAN for hours and didn't find that!

    After quickly looking at it, it looks like Object::Realize::Later impliments the same sort of thing, but goes about it in a very different way, and with a different philosophy.

    Class::LazyObject is all about invisiblity. An assumption I made in Class::LazyObject is that the Lazy Object could be used invisibly in the place of an inflated object, meaning it could be easily grafted on to a program even after the program had been designed. Object::Realize::Later seems to require you to have planned to use it, restricting which method names you can use in your inflated objects. (It looks like it pollutes its lazy objects' namespaces with methods named "becomes", "believe_caller", "realize", "source_module", "warn_realization", "forceRealize", "willRealize" and "warn_realize_again ", this could be problematic if the inflated class uses methods with these names.)

    An even greater major difference is in how copies of lazy objects are handled. (Since objects are really just refs, after $object2 = $object1, both variables refer to the same object, and any changes to $object1 will be reflected in $object2). This means that, after $lazy_object2 = $lazy_object1, if $lazy_object1 is inflated, $lazy_object2 should be a reference to the inflated object. While Object::Realize::Later leaves the user to worry about how to go about implimenting this (thought it does give suggestions in the documenation), Class::LazyObject specifically handles this for the user, ensuring that the correct behavior always occurrs. Additionally, it does this without reblessing the lazy object.

    Another thing that O::R::L doesn't appear to be able to do is handle AUTOLOADed methods in the inflated class. Class::LazyObject can handle them.

    Additionally, O::R::L doesn't appear to have support for overloaded operators on lazy objects. I am already working on automatic operator overloading of lazy objects, which should be in a future release.

    While it will be worth contacting the author of Object::Realize::Later, it seems like our two modules are headed in slightly different paths. I can think of several instances in which Class::LazyObject would fit but Object::Realize::Later would not. I still think Class::LazyObject warrants its own place on CPAN.

    Thank you for finding Object::Realize::Later, though.

    Edit:Added more information.

    Once it's Turing complete, everything else is just syntactic sugar.
      If you decide to upload to CPAN, you should definately include a compare/contrast to Object::Realize::Later in the POD/README. Contact the author first to make sure what you are saying is accurate. This will help people decide which module is right to use in what situation.

      Cheers - L~R

      That's cool -- it's just a sad thing when you can't find something on CPAN that could have an impact on the work you're doing, quirky naming schemes and all. Best of luck!

      M-x auto-bs-mode

      Hi, I'm the author of O::R::L. You may want to have a look at the presentations I gave on various YAPCs as well: may help. ORL is also invisible. Even isa() and can() are fake. The use of 'use XYZ keyword' does NOT add 'keyword' to your namespace: it only calls XYZ::import(). When Exporter is used in XYZ, then the name-space is poluted, but not in the ORL case. About copy: my docs must be unclear. It explains that there is the danger that there are two references to the UNinflated object. When one handle gets inflated, the other may not. Your 'inflation' method must take care about it. Not handling AUTOLOAD? Why not? It should do that. Overloading is a nice idea, not in ORL... however overloading is quite nasty. You can use overloading on the lazy objects, but not automatically simulate the overloading of the inflated. Be aware that ORL has already proven itself in various applications: it works. For instance, my Mail::Box module uses all corners of its power. As far as I can see, both modules try to do the same. But I don't mind an alternative implementation.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://297470]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (3)
As of 2022-05-25 19:18 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (90 votes). Check out past polls.