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

I can't help thinking that if you return an object representing the results of one set of manipulations performed on one set of data, and the user passes this back to you via a call to manipulate a completly different set of data, you have an unresolvable problem?
I don't really see this a being a problem. This is no different from user passing in the wrong file name to a call.

Some manipulations might require other stages to be performed first and that can be tested for.
If the user passes the wrong object that passes all tests, there isn't much I can do about it - I'd hope the user knows what order they want to do things in.

I can't think of any neat way of taking this away from the user, and honestly don't see any need to do so.
Simplifying the representation of the file(s) to process is probably all I need.


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: Tracking processing by returning objects?

Replies are listed 'Best First'.
Re: Re: Re: Tracking processing by returning objects?
by BrowserUk (Patriarch) on May 17, 2003 at 12:25 UTC

    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();

    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

      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; }


      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.

        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; }

        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