in reply to An object replacing itself

First off, your list() method should return an iterator, which you would use as while (my $object = $iterator->next) { ... }. Each item in a list shouldn't know who the next item is - that's for the iterator to know.

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.

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

Replies are listed 'Best First'.
Re^2: An object replacing itself
by ryantate (Friar) on Sep 23, 2004 at 20:58 UTC

    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.

[reply]
      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

[reply]

        Thanks for your reply. By the time you wrote it, I'd already coded a proper iterator.

        I guess I liked the idea of avoiding the whole IDEA of an iterator, it would be one less THING to have to learn about, assign to a variable, conceptualize, etc. One less pair of parentheses in my TT2 template. One less class to write.

        But if the idea is already common and widespread -- in fact, de riguer -- why swim against the tide ...

        Thanks again

        RT

[reply]

      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.

[reply]

        Why is a dedicated iterator a better way to get the job done?

        Memory use? Maintainability?

        Why not store the collection inside the object? Am I going to hit trouble down the road?

        I would love to be educated on this. Please tell me why you believe this. Otherwise, I fear I may erroneously conclude it is merely inflexibility/bigotry on your part.

[reply]

      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.

[reply]
[d/l]
        See my reply further on in this thread. Joel is discussing a hack to get around the poor interface of DAOs. I don't think he'd advocate this solution in the general sense.

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

[reply]

        Thank you for your input. I really appreciate it.

        I also agree there is value in writing code other Perl programmers can more easily understand. I'll have to give this all some thought.

        As far as doing things in Perlish manner, someone wise once told me There is More Than One Way To Do It ;->

        (PS I have no idea if this is common VB code. I haven't written a line of VB in my life.)

[reply]

In Section Seekers of Perl Wisdom