On Fri, 16 Mar 2001 16:30:04 -0500, Scott R. Godin wrote:
>This doesn't precisely answer your question, but...
>
>always do
> return bless $obj, $class; # this, straight from the OOP book.
No, it doesn't answer the question. In fact there's nothing wrong with
the original code if you don't do any subclassing. Otherwise, it might
use the wrong methods for the objects, but that is it.
The problem here uses object that CONTAIN other objects, not subclass
their classes.
On Thu, 15 Mar 2001 14:27:33 -0700, Keary Suska wrote:
>I have a main script (package main) that instantiates a Logger (no relation
>to Unix command), an Error, and a Result object, in that order. The Error
>object uses the Logger and Result object for certain functions. The logger
>object is passed to the error object constructor which adds it to its hash:
>
>sub new {
> my($class, $log_obj) = @_;
> my $obj = { log => $log_obj ...etc... };
> return bless $obj;
>}
>
>The Result object is added afterward using an object method. The problem I
>am having is that when the Error object's DESTROY method is called, the log
>object element ($self->{'log'}) is undefined. I thought it shouldn't be
>destroyed, since there would be an outstanding reference.
That doesn't make sense. If you ask me, there IS no log object. If the
log object did exist but was destroyed prematurely, there would still be
a, invalid but definitely defined, reference in $self->{'log'}.
--
Bart.
