Personally, assuming there's nothing more to your example,

Cars and dogs and CD collections are boring, I livened it up a bit. In your example, you do some things I consider to be really odd in the context of a larger app, and it takes away from the meaning of my hypothethical example, perhaps intended to mock it? Do you ever create anonymous data, do things to it, and completely discard it? No. Your example has problems in this regard -- it has hardly any application, even if you were writing a real world application about RandomSpaceTravellers. Your example, as you posted, would raise red-flags in my code review. How are you going to extend that convulted algamation of greps and sorts? What was it you were trying to achieve? Is everything done with side-effects since you don't keep any of the objects around?

If you're implementing an aggregate ... we already have a perfectly good aggregate - it's called an array. If you need a named aggregate, use a hash. How does this additional indirection benefit us?

Which was my point exactly when you originally said the following puzzling comment:

If you need an aggregate, create an aggregate. This, to me, would be a red flag in a code review.

You didn't state why this would be a red-flag, but I assume you have reasons, and you later went on to say that arrays are all well and good (as I maintain). So if you are for whatever reason making an aggregate (why would you? -- but maybe you have to pass a dragonchild code review where you work and must), yes, you are going to come into a case where you need to iterate over a collection, which is in disagreement with:

Personally, I don't see a need for calling the same method on a number of objects

As the many examples show thus far, there are plenty of valid uses ... your particular coding style may dictate otherwise, though yours is not the only style. There are uses, and I originally posted something much more similar to Fletch (which also has uses, even in simple scripts) -- but decided I'd liven it up a bit.

We probably need to agree to disagree here. We have contrasting opinions, and perhaps I will stick to replying to the original thread posts on PerlMonks before I get accused again of making examples with 'nothing to them'. But again, I was never maintaining we needed a function-multiplexor class, I'm only saying (as most monks will back me up) -- grep and map and foreach are good functions, and calling methods on a list isn't so goofy as you seem to imply.

If an aggregate served a purpose beyond simple aggregation, that's one thing. But, to create an aggregate class simply to collect things ... that's the red flag. We already have something that collects things - an array. Unless you're spicing up the array somehow, there's no reason to create an additional syntax just to be more OO.

Some reasons I could think for creating an aggregate class:

• An iterator. Iterators are, at their base, arrays, but they often provide much more than simple iteration. I use them to provide a single interface into various forms of lists.
• A factory. A factory can also be an aggregate, providing both the ability to create and to iterate. This can be helpful.

Remember - we don't want to go the Smalltalk/Java route where you have a Collection, SortedCollection, Set, Bag, etc. Or, the C++ version where each of those are templated to comply with strong typing. Leverage what exists - don't reinvent the wheel.

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

Good, thanks for explaining yourself. My apologies for the knee-jerk reaction, I should have noticed our mutual communication error earlier and pointed it out, but it was a little hard to grok. We are at least 90% on the same page, which for all practical purposes is good enough.

But, to create an aggregate class simply to collect things ... that's the red flag.

Then this is why we've had all of this confusion. I had no idea you were pointing out what you considered a red-flag in Limbic's code, rather than mine (I was using map). Thanks for clearing this up. To be fair to Limbic, there are analogous situations where this might make sense, for instance if he was implementing some sort of spiffy event notification list or message dispatch table, in some form or another -- but it would need some tweaking to be that versus what I see in it now.