Re: Re: Re: Re: Tracking processing by returning objects?

I've starting coding up my new and improved module, including feedback from BrowserUk.

The use of statements such as return $self->new( "$self->$filespec.munged" ); doesn't work, as the class fed to the new() method by all other methods is the object, not it's class so I used:

sub new {

    my $class_self = shift;  # Could be a class, or an already blessed
                             # object from another method.

    my $class;

    if (ref $class_self) {
        $class = ref $class_self
    } else {
        $class = $class_self;
    }


    my %arg   = @_;

    my $self = { file => $arg{'filespec'}  };

    bless $self, $class;
}
[download]

If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong.
That way everyone learns.

Comment on Re: Re: Re: Re: Tracking processing by returning objects? Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Tracking processing by returning objects? by BrowserUk (Patriarch) on May 19, 2003 at 03:33 UTC
Yes, sorry about that BazB. The pseudocode was only illustrative :). One thing with your solution though. I've seen merlyn at least, and possibly others condemn the practice of using `sub new { my $proto = shift; my $class = ref( $proto ) \|\| $proto; my $self = ....; ... return bless $self, $class; }` [download] as "cargo-cultish" behaviour. This is a somewhat condensed version of your solution. The problem apparently being (if I understand the argument correctly), that it makes no distinction between calling `Foo->new();` to create a new instance and calling `$instance->new();` to make a clone of an existing instance. I'm not sure that this affects you in this case, but merlyn is much wiser in these things than I, so you probably ought to read his advice for yourself. I found one reference of his at ref($proto) - just say no! which goes way back. I know that there have been many more instances in the more recent past. If your lucky, he'll get over the fact that I'm involved and give you the gen on this himself. Update: I found another, slightly more recent discussion, including an alternative method of achieving what you need to achieve (by putting the onus on the caller rather than in the `new()` call) here, and a better explanation of the issue by dragonchild here. In fact, the whole thread is well worth a read as most of the big hitters around here step in and argue the case, which is a great help in letting you make up your own mind on the issues. It helped me a form an opinion anyway:) Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller	[reply] [d/l] [select]
Re ^6: Tracking processing by returning objects? by BazB (Priest) on May 19, 2003 at 08:17 UTC
Ah! In the past, the whole `$class = ref $class \|\| $class` argument went over my head - it now makes some sense. Having read the threads BrowserUk (++) pointed out, I've yet to make up my mind. Having a `clone()` method seems like a Good Idea, and takes some clutter away from the `new()` method. That said, I can't see the problem with `$class = ref $class \|\| $class`, provided there is a need for it. Just putting it in all code seems pointless. Update: merlyn posted •Re: Re: Re: Re: Mmmm ... cargo cult progamming is nummy! and made up my mind - `clone()` it is! :-) If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong. That way everyone learns.	[reply] [d/l] [select]


XP is just a number
	PerlMonks