in reply to Re^2: An object replacing itself
in thread An object replacing itself

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

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

Replies are listed 'Best First'.
Re^4: An object replacing itself
by ryantate (Friar) on Sep 24, 2004 at 05:05 UTC

    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]
      As many are fond to point out - complexity exists, and it will make its prescence felt, no matter what you or I may want. So, the goal shouldn't be to reduce the complexity of the problem, but instead to channel that complexity in order to reduce the complexity of the solution. If the problem requires that extra thing to learn about in order to reduce the solution's complexity, then that is the true Laziness. Trying to skip a few characters in typing ... that is false Laziness, and should be avoided.

      Now, about your de rigeur argument ... that's how you got into trouble in the first place. You took a solution from a Great in his field and said "If XYZ says it works, then it must be the only way." Just because 90% of a group do things in a certain way doesn't mean it's the right way. Granted, it's the way you should probably check out first, if only to know what it is. But, you should understand the solution, why the solution works the way it does, what problem(s) does it solve, and when is it not applicable.

      An iterator isn't always the right way to iterate through the items in a set. There are times when it's appropriate to use other concepts. However, I've never run into one. YMMV

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

In Section Seekers of Perl Wisdom