in reply to Re: Re: Tracking processing by returning objects?
in thread Tracking processing by returning objects?

I guess my explaination left something to be desired, so here it is in slightly expanded pseudo-code.

The basic idea is that rather than each operation on an instance of Foo returning an instance of some State class, it returns a new instance of itself. To perform any further processing on that state of the data, he invokes the operation directly on returned object.

That way there are no seperate objects to be passed back to you wrongly. 

package Foo;

sub new{
    my ($class, filespec) = @_;
    # check for existance, other init stuff
    return bless {file=>$filespec }, $class;
}

sub sort{ 
    $self = shift;
    system( 'sort', $self->$filespec, '>', "$self->filespec.sorted" );
    return $self->new( "$self->$filespec.sorted" );
}

sub munge{ 
    $self = shift;
    system( 'munge', $self->$filespec, '>', "$self->filespec.munged" )
+;
    return $self->new( "$self->$filespec.munged" );
}

1;
package main;
# Start with a object created  by the user.
my $data = Foo->new( 'datafile' );;

# Munge it two different ways and get two seperate objects back repres
+enting the two new states
my $sorted = $data->sort();
my $munged = $data->munged();

# Further processing on the new state is invoked directly on the new o
+bject
my $sorted'n'munged = $sorted->munge();
my $munged'n'sorted = $munged->sort();

# Or even pipeline them
my $sorted'n'munged'n'sorted_again = $data->sort()->munge()->sort();

[download]

Anyways, if I understood your question correctly, that's how I would do it.

HTH. Sorry, if it doesn't.

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

Replies are listed 'Best First'.
Re: Re: Re: Re: Tracking processing by returning objects?
by BazB (Priest) on May 18, 2003 at 17:00 UTC

    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.
[reply]
[d/l]
[select]

      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]

        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]

In Section Seekers of Perl Wisdom