in reply to Memory Managment with Subroutines and Objects

Maybe you want to learn about how Perl manages memory? You don't need to manage memory yourself (as you would have seen by monitoring the memory usage of your program as it downloads some files).

Also, if you want to call a method on an object, it helps to read the documentation as to what methods are supported. Neither ->delete nor ->die nor ->gibberish are documented there to work, so what makes you think they should work?

As programs do not share memory in a way that both can modify it and see the modifications unless you make very specific preparations, you cannot pass Perl objects between programs (or "scripts" as you call them). Not even in Java can you do that, or at least, it would be just as clumsy as in Perl, by storing all payload data in a file on disk and then restoring the object from that payload data. I'm not sure what you intend to gain from such an approach.

Replies are listed 'Best First'.
Re^2: Memory Managment with Subroutines and Objects
by Anonymous Monk on Dec 28, 2010 at 23:28 UTC

    Thanks for responding. The reason I Thought that delete and die might work is that die is in the documentation as an internal method (so I thought it was worth a try) and I seen delete used in the documentation for HTML::TreeBuilder (so I thought that it may be a method that is common to all perl objects in the same way that there is a set of methods that are inherited by all Java objects from Java's object class). Gibberish was a control on my experiment, as i did not expect it to be defined at all for anything.

    I assume this is a misunderstanding as for the sharing objects between programs. I do not want to do this I just want to call routines from another file and have them return objects (with the added benefit of having a reference to that object in the caller and callee file). This will work in java and is done pretty much as I described. If the code that I provided is saying something else, let me know, I do want to improve my perl understanding

    Again thanks for your time

      Ah, I see now that you are loading the "other script" via require. A more common approach would be to turn the first "script" into a Perl module, by naming it with a .pm extension and then loading it, still via require or use.

      As memory management in Perl is mostly automatic, you don't have to do anything special to release the WWW::Mechanize object (as its documentation does not mention anything special either). If you want to reuse the same WWW::Mechanize object over and over, just store it in a variable at script startup and then use it from there:

      package DownloadUtils; use strict; use vars '$mech'; sub get_mech { WWW::Mechanize->new(); }; $mech = get_mech(); sub get_file { $mech->get("$url", ':content_file' => "$file"); }; 1;

      If you only simply want to download some URLs, LWP::Simple might be the easier approach. But it offers less convenience when it comes to cookies etc.

        Thanks again, I want to interact with forms and that is a big reason I choose Mechanize and at first glance, it does not appear that simple will do that. If you know of any package that does and is easier, please let me know.