I see the performance increase, but I feel pains with that change ;)

I'm not happy with having to have had to implement the Iterator myself but I hate (with a passion! ;-) ) the loss of type information when using ArrayIterator. The whole point of using a collection is to have clear types for in and out. With your change - again, I do understand it and the reasoning - we only have 50% of the type information.

Is there a work around for that?

Side nodes: Your getIterator method does not have a return type and the formatting is wrong according to my code style.. :-p

Is there a work around for that?

sure, I have added necessary static analysis type annotations

Side nodes: Your getIterator method does not have a return type and the formatting is wrong according to my code style

fixed, thanks.

if you are fine with it, it would be great we could merge #24 before this one here (as we will get conflicts and this one here will be easier to resolve)

I not yet verified whether this changes break PHPUnit usescases.

I think we should add a compatibility check with PHPUnit versions in CI

Is there a work around for that?

sure, I have added necessary static analysis type annotations

Thanks!

It still feels wrong to have a generic return type that basically has zero information on what is the Iterator going to iterate over on the language level. This is not what I understand under strictly typed ;)

But I guess with the annotation it is good enough to be considered a pragmatic solution.

I'm pondering about the change in the XMLSerializer now: Your change, while I did not verify that, seem to be making it less efficient by performing a null check on every loop while my original implementation did not require this.

If we'd keep the ArrayAccess on the collection, this change would not be required. It would also remove the need to make $previousToken nullable.

What do you think?

I'm pondering about the change in the XMLSerializer now: Your change, while I did not verify that, seem to be making it less efficient by performing a null check on every loop while my original implementation did not require this.

If we'd keep the ArrayAccess on the collection, this change would not be required. It would also remove the need to make $previousToken nullable.

What do you think?

We could actually also just use $iterator->current(), couldn't we? Instead of doing this in the loop...

I'll merge this with my suggested change.

There are quite some side effects that I'm cleaning up now:

• There are a lot of failing tests that used ArrayAccess. So this is certainly a BC break.
• Removing ArrayAccess removed a full set of features, even though I'm not sure being able to modify the collection by offest was actually useful ;)
• After the change, the CollectionException is superfluous.

Also all my Tokenizer tests fail as I used a serialized collection to ensure it's not broken.

Done.

Thanks for cleaning it up. Why did CI not fail on said tests?

https://github.com/theseer/tokenizer/actions/runs/19149696040/job/54736453289

The tests fail - but github doesn't notice that as a problem. Interesting.