Re: Re: Method Calls on multiple objects

[flyingmoose]

Personally, I don't see a need for calling the same method on a number of objects. If you need an aggregate, create an aggregate. This, to me, would be a red flag in a code review.

# make 8 random aliens
@lifeforms = map { RandomSpaceTraveller->new(); } (0..8);
# find out who is klingon
@klingons = grep { $_->get_species() eq 'klingon' } @lifeforms;
# blow the klingons away
foreach (@klingons) { $kirk->shoot_at($_); };

As evidenced above, I disagree. There are those of the functional school (of which I am quickly becoming a convert), who would say mixing OO and functional concepts in the same program is extremely funky in a good way.

Another point -- What if you are implementing an aggregate? Well, you need to know how to dance in aggregate school.

[tilly]

I'd agree with dragonchild. Yes, combining those styles is good. But strive to do it naturally, and you won't likely find the proposed method useful in many situations.

Remember, many small utilities that fit together in flexible ways. That's the ticket. :-)

[flyingmoose]

But strive to do it naturally, and you won't likely find the proposed method useful in many situations.

I am not psychic here, what does 'more naturally' mean to you? Please elaborate and we can debate opinions on an equal front, but one saying 'what you do is not natural' is a assault on code without backing -- please explain your convictions and the merits of one style over another, and what is 'more or less natural' to you. You may find there are many of those who disagree, and as it stands, we don't even know what you mean. It's sort of like me saying "I am flyingmoose and your code is wrong because I am flyingmoose". That doesn't help folks, really it doesn't, and perhaps you need to look more carefully about what you are saying when you say it.

Also, 'the proposed method' ... mine? Or Limbic~Regions. As I have been maintaining many times, I don't like Limbic's proposed method. I'm talking foreach, grep, and map! Seriously... are you arguing against foreach, grep, and map? Because it appears you have me confused with Limbic (as does dragonchild). Personally I think a simple use of non-combined map's or grep's is very natural, very readable, and obvious. I don't like dragonchild's particular re-coding of my Star Trek example -- I find that very unnatural, inflexible, and quite the maintaince problem.

[tilly]

Well since "naturally" is an aesthetic judgement, it is hard to provide a precise definition. Rather you can provide contrasting examples and get a sense of someone else's tastes.

But the reason for my comment is that Perl has enough ways to distribute actions over lists in a concise manner (map, foreach, etc, etc) that introducing a very specialized one doesn't meet the utility threshold to be worthwhile.

But if you disagree, try to produce an example where such a method would make sense, and I'll produce an example that doesn't use the method, and we can compare. If it really is natural for your problem domain, then it shouldn't be hard to come up with a good example...

[dragonchild]

So, in your example, the aggregate would be of the RandomSpaceTraveller objects, right? Personally, assuming there's nothing more to your example, I would write that as:

$kirk->shoot_at( $_ ) for
    grep {
        $_->get_species eq 'klingon'
    } map {
        RandomSpaceTraveller->new
    } 0 .. 8;

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?

[flyingmoose]

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

You missed the point. My commentary is there comes a time when it is required to do one thing to many objects (I don't like L~R's suggestion, really, I'm just talking about map and foreach and grep), and I never make examples where there is 'nothing more to them'. These were examples of how they might work in a larger context, and I really don't like being picked apart because I decided to chose a creative example for your amusement.

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.

[dragonchild]

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.