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.

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

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

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.

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.

It is better design. You've separated your concerns when you keep your collection separate from the thing the collection contains. This is a bit like a box that contains other boxes that also contains itself. The primary thing here is to keep the collection object separate from your contained object. Or also, to keep the container out of the things that it contains. You might, if you wished, provide a method on your collection which could do the ->next operation for you.

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.

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

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

Sure, there is more than one way to do it, but most of those are the wrong way. Jumping through hoops just to do it "a different way" is silly.