Hello again,
Replying to this one since it is the shortest... Thanks for the
responses...
The illustration, admittedly, was sparse at best master Drieux :-)
However, I do want to have independent instances beyond the A.pm.
Maybe I am making this too difficult, not sure yet, but I will do
some testing. Seems that both options provided are effectively
the same, so I will let you know..
I have written a module that has worked well for a number of years.
However, after purchasing the next installment of 'Learning Perl',
'Learning Perl Objects, References, & Modules', I have seen some
amazing things that I had never thought of in regards to inheritance.
BTW, if you liked 'Learning Perl', you will love this one too...
For a while now, I have been wanting to break the module down (it
was getting near the 200K mark without the docs). It includes
some use()s that I take a hit for (some of the servers it has to
run on do not have mod_perl). So, I was trying to limit the
startup requiring the separate chunks that have the use()s
(socket.pm is use()ed in two routines that get called infrequently
for example).
The problem was including a master set of objects with the newly
created objects from the child modules. Passing the parent object
ref worked, but I did not like having to add the additional code...
But, lets take it a step further... Lets capture
$main::SIG{__WARN__} && $main::SIG{__DIE__}. Lets set up the
capture like so:
$main::SIG{__WARN__} =\&A::warning;
With a routine like so to handle it:
sub warning {
my $self=shift;
my $message=shift;
push @{$self->{warnings}}, $message;
}
Now, we can spit all the warnings out to an HTML page at our
leisure instead of it causing an HTTP header error. Not only
that, but I can call out warnings throughout the code for
debugging, to warn a client that they have some conflicting data
in a several page form input that compares that input to a database
server side, or any other number of reasons. But one problem, when
the system catches a warning, there is no object sent, and $self is
populated with the message itself. So I thought about it and came
up with this:
use vars qw($OBJECT);
$main::SIG{__WARN__} =\&A::warning;
sub new {
my($class)[EMAIL PROTECTED];
my $self={};
bless $self, $class;
$OBJECT=$self if(!$OBJECT);
# Set $OBJECT to original created object only
return $self;
}
...
sub warning {
my $self=shift;
my $message;
if(ref($self)) {
$message=shift;
} else {
$message=$self;
$self=$OBJECT;
}
push @{$self->{WARNINGS}}, $message;
}
BUT, and this is a big but, if the warning happens in a child
object, the $self is a different object and is lost forever when I
call on $self->{WARNINGS} to spill its guts. The only way I was
able to do it was to pass the parent object to the child. But
there are a lot more issues than just this one...
Shawn
BTW...
sub new
{
my $class = shift;
my $self = {};
bless $self, $class;
} # end of our simple new
Can be simplified even further to:
sub new { bless ( {}, shift ) }
But, that seems a bit cryptic :-) I saw this in the Perl Cookbook
a while back...
> -----Original Message-----
> From: James Edward Gray II [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 05, 2004 7:20 PM
> To: drieux
> Cc: Perl Beginners Mailing List
> Subject: Re: Sharing instances of objects between packages
>
>
> On Jan 5, 2004, at 6:30 PM, drieux wrote:
>
> >
> > On Jan 5, 2004, at 2:51 PM, James Edward Gray II wrote:
> >
> >> sub new {
> >> my $class = shift;
> >> my $self = $class->SUPER::new( @_ }; # call class A
> constructor
> > --------------------------------------^
> > oopsie should have been a ")"
>
> Good catch. Sorry about that.
>
> James
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
