Thanks again Rob some great advice, Perl's ambiguity could also be described as its flexibility I guess.
I am trying to learn how to create OO modules but that clone path I took, lead me away from what I was actually doing. I see it is not an essential element in creating object structures, I don't think I need it at all. Final question: (who am trying to kid.) The instance methods of my object call several DBI related functions to acquire and store info. Would it be a good idea integrate the connection/disconnection functions into the constructor and destructor of the object? Thus allowing new() to initiate a DBI connection on creation of an instance of the object, and DESTROY to deal with the disconnection of the DBI link. I think personally this might be a bad idea, but then I look at the alternatives: 2) A single DBI connection for all object instances. Having a class-wide DBI handle which would be initialised by the first object instantiation. I have found documentation on an END method for package garbage-collection, which could deal with closing the DBI connections. 3) No integration of DBI and my object. Any DBI connection is made in main and must therefore be made before any calls to my object can be made successfully. Leaving my object effectively as a non-functional package, unless a user has setup all the required DBI access. *sigh* So now the original idea doesn't look so bad, apart from the possible overhead of excess DBI connections. Which is where idea 2) above comes in, with a package variable, requiring a bit more coding in the class methods. This is what always used to catch me out with OO design, the decisions on where to keep certain data elements that don't fit clearly into a specific place. I think I need to lie down, Tom Norwood. -----Original Message----- From: Rob Dixon [mailto:[EMAIL PROTECTED] Sent: 12 March 2003 21:45 To: [EMAIL PROTECTED] Subject: Re: Inheritance and clone() Hi Tom. You're a bit off-track here with your appreciation of object methods, but I'll try to put you straight as well as answer your questions as they are. Tom Norwood wrote: > Cheers Rob, below is the clone() from URI::WithBase > (the base class of URI::URL). > > sub clone { > my $self = shift; > bless [$self->[0]->clone, $self->[0]], ref($self); > } > > Which is the last package included with 'use' in my > original example piece of code, so I assume this > clone() is the prevalent version. There is not a 'prevalent' version of a method. Perl's very like any other OO language in that an object's method will be a routine which depends on the class of that object. If I say my $url = URI::URL->new( .. ); then I am calling the routine URI::URL::new (or perhaps one that URI::URL has inherited from a base class, such as URI::WithBase::new). Similarly with my $clone = $url->clone; I am calling URI::URL::clone or an inherited clone() subroutine. In the same way, objects of class HTTP::Request or LWP::UserAgent can have their own 'new' and 'clone' methods. If they don't then these methods can't be called through such objects - the existence of a method of the right name in a different class is irrelevant. > This is what I have as my constructor: Getting into the actual code of object methods is nearly always unnecessary: the interface is all you should be interested in, which should be fully explained in the POD within the module and therefore accessible via perldoc URI::URL or the equivalent. The author is always free to change the way his methods work as long as the interface remains invariant. > > # *(A)* > > sub new { > my($class, $init) = @_; > my $self; > if (ref $init) { > $self = $init->clone; > } else { > $self = bless { > 'id' => undef, > 'username' => undef, > 'contents' => {}, > # *(B)* > 'status' => 'B', > 'updated' => undef, > 'created' => undef, > }, $class; > } > } > > My next question is: What is the difference between > variables declared (A) outside the constructor Variables can be declared at *(A)* which belong to the package as a whole, and therefore apply to all instances of this class, but again you won't need to know about them unless the documentation tells you how to use them. Interaction with an object's internal data is nearly always done entirely through the method calls. > and those included (B) in the blessing within the > constructor? The bless function (a Perl built-in function) simply associates a data reference with a package name to so that method calls can be resolved. The line in your constructor above says $self = bless { .. }, $class; which is blessing an anonymous hash reference into the package named in $class (presumably 'URI::URL') and assigning the result to $self. All of the hash contents are specific to this instance of the class, as a second call to the constructor will create a new, separate anonymous hash. > I guess I really just don't understand the > documentation on bless, I used to do a quite bit of > C++ a few years ago and like the OO approach but Perl > is so ambiguous and cryptic at times it turns my > brain inside out. All bless does is to associate a package name with a data reference. However, unless you're writing an object module you shouldn't need this level of knowledge, which will only confuse you. Read the documentation to find how to use an object's method calls, and _remember_ that methods with the same name from different classes could do entirely different things. > How I understand bless is that it tells Perl to treat > an item pointed to by a ref as an object. But what > does that mean in actual terms, the access method for > package variables doesn't change. No, the access method for package variables doesn't change, but DON'T ACCESS THEM! As I've pointedly said already, you almost never need to do anything that can't be done through method calls. All you need to know should be in the documentation. Don't take advantage of the fact that Perl classes are distributed in source form: pretend they're compiled into a binary object library! I hope this helps. Rob -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email has been scanned for viruses by NetBenefit using Sophos anti-virus technology This email has been scanned for viruses by NetBenefit using Sophos anti-virus technology -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
