Add support for iterating over forces.

[jonathanmclaus]

Iterating over forces requires a code right now. In lieu of adding support for closures or converting every force to a list / set, I'm adding these methods so forces can at least be used in a standard for-loop. Iteration is destructive on the original force so iterator should be used to avoid that. I'm putting it in a separate file so people don't accidentally iterate over a force without understanding that it is destructive.

This can be used like:

for target in bj_FORCE_ALL_PLAYERS.iterator()
    print(target.getName())

[jonathanmclaus]

This can't be unit tested because GetEnumPlayer does not work at compiletime it seems.

[Frotty]

Hi, thanks for the PR. I don't really understand your explanation though - the implementation seems equivalent to the groups iterator - the iterator func copies the values into another force. Thus for p in f should correctly leave the original force intact, and for p from f would remove the processed player entries but not destroy the force, as long as .close() isn't called. I don't really understand the example, wouldn't it most likely lead to another .iterator() call on the iterator since you're not using "from"? Did you tests this or rather check the generated code?

In any case, the usage of iterators should be consistent and not strangely differ just for forces.

In lieu of adding support for closures or converting every force to a list / set, I'm adding these methods so forces can at least be used in a standard for-loop.

Why not add support for closures?

This can't be unit tested because GetEnumPlayer does not work at compiletime it seems.

Should be an easy addition since it's equivalent to GetEnumUnit I think.

[jonathanmclaus]

I didn't realize .iterator was automatically called. So you're right, it's not destructive.

Adding support for closures was more involved and I thought for-style loops were preferred over forEach.

I'm not familiar with what's required for compile time functionality of natives.

[Frotty]

I didn't realize .iterator was automatically called. So you're right, it's not destructive.

Then I would move it into the Force package instead of its own package.