Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Re: RFC - Class::LazyObject

by QwertyD (Pilgrim)
on Oct 08, 2003 at 04:10 UTC ( #297472=note: print w/replies, xml ) Need Help??


in reply to Re: RFC - Class::LazyObject
in thread RFC - Class::LazyObject

*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.

Replies are listed 'Best First'.
Re: Re: Re: RFC - Class::LazyObject
by Limbic~Region (Chancellor) on Oct 08, 2003 at 12:37 UTC
    QwertyD,
    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

Re: Re: Re: RFC - Class::LazyObject
by lachoy (Parson) on Oct 08, 2003 at 11:32 UTC

    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!

    Chris
    M-x auto-bs-mode

Re: Re: Re: RFC - Class::LazyObject
by Anonymous Monk on Oct 09, 2003 at 06:49 UTC
    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?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2020-06-06 15:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you really want to know if there is extraterrestrial life?



    Results (41 votes). Check out past polls.

    Notices?