But, if you insist on doing this, you want to do the following:

sub load_next{
    my ($self, %arguments) = @_;
  my @next = @{$self->storage_next_list};
  my $new_self = shift @next or return;
  $_[0] = $new_self;
  $self->storage_next_list(list=>\@next);
  return $new_self;
}
[download]

This is very poor coding and should be avoided.

I do appreciate your comments.

You may notice that I linked to someone else I respect using the setup I describe -- or at least doing so as near as I can tell. I would be grateful to know why you consider this "very poor coding" and advocate a different way of doing things. I have read Conway's book on OOP, the Camel several times over, never have I read, as far as I can recall, why this is a bad thing, so I'd appreciate knowing why I should join you in throwing rocks at this practice.

This isn't a Perl question - this is a general programming question, so you wouldn't have seen it in any Perl-specific book, except in one of those sidebars. That's why places like here exist.

The great Joel Spolsky

• is wrong in the general context
• is talking about something else

The solution he is advocating ... there is an issue with how DAOs (Data Access Objects) are created in Java, JSP, ASP, and .Net applications. The interface is poor, to say the least. Joel is discussing a fix for a specific issue that causes many Windows developers great pain. This is similar to some of the solutions in ANSI C for memory management.

The reason that the solution is poor in the general context has to do with what's known as "Separation of Concerns", more commonly known as "Who cares?". Items in a group should have no knowledge of the fact that they're in a group. The group should know how about the items in it and how to iterate over them. Often, a helper object is created, called an iterator, which can be exposed to the client that allows for syntactic sugar in iteration. (It also allows for more than one iterator to exist at one time.) The point is that the items in the group don't care about the other items in the group. The only entity that cares about that is the group itself. So, it should be the only one that can do anything about group membership.

Put another way - finding the next member is closely linked to adding a new member. Would you ask an item in a group to add another member to said group? I wouldn't.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

You have better ways to express this sort of thing - a collection should hand these objects out. An object that knows what is "next" already has an implicit collection somewhere otherwise it wouldn't know where it was and what came after it. dragonchild is right and you shouldn't be doing this.

While I agree with dragonchild and diotalevi that you shouldn't do this, I'm not quite sure it's a terrible idea, per se. The only reason I would advise not to use it is, in Perl, there's a very common idiom for iterators:

    my $notelist = My::Dashboard::Note->list;
    while (my $note = $notelist->next) {}
[download]

What you're trying to do may be common in VB-land, and there may be nothing inherently wrong with it, but you're not writing VB code. You're writing Perl code, and you should try to write things in a Perlish manner.

This is what for(;;) and container objects are for.

for ( my $notes = My::Dashboard::Note->list,
      my $note = $notes->first;
      $note;
      $note = $notes->next )
{
    print $note->headline,
          $note->created,
          $note->body;
}
[download]

If I understand correctly, you want the object in the client code to become a different object when a particular method is called on it, correct? If this is want you want you can simply assign the new object to $_[0] in the method. See below:

#File Foo.pm
package Foo;

sub change_var
{
  $_[0] = 'Bar';
}

# File main.pl
use Foo;

my $var = 'Foo';
print "$var\n"; # prints "Foo"

Foo::change_var($var);

print "$var\n"; # prints "Bar"
[download]

In Perl the @_ array actually contains the arguments passed to the subroutine. Modifing @_ directly modifies the variable in the clients namespace. Does that make sense?

I'll try that, I may have made a bad assumption about something I tried before ...

I believe this is a fairly common pattern for object oriented design.

My experience suggests the opposite. Having an object that you're holding a reference to automagically morph into a different object when a method gets called somewhere else is an anti-pattern. It can lead to situations that are wickedly hard to debug, particularly when you pick up the code six months later, and have forgotten just how clever you were and where.

I have found a similar construct useful in the context of a related class hierarchy, where an object turns itself into an object further down the inheritence chain. An example is this: You have a base file class. The constructor of that class takes a file name and provides back an object representing that file. Now suppose you have a subclass for directories. If you want to maintain a simple file name contract with the outside world, you could have the base file class figure out if the given file name is actually a directory and pass back an object of the derived directory class if it is.

I've had similar interfaces where the decision can't be made at construction time. In the file example, maybe you first have an object representing a remote file on another system, but it's not until some connect method that more details of that object are filled in and you realize the remote file is actually a directory. I've morphed objects into objects of derived classes in cases like that by reblessing them.

I don't consider this bad coding practice since you've maintained the contract, at least in a loose sense: The object is still a file, it's just a more specific kind of file. There are obvious flaws in this design, but in some cases I've found it to be the best choice, given that any approach has flaws.