Discussion: What should happen to the TextIterator?

[mhsdesign]

In #3278 i was forced to adjust the types in the TextIterator and it came up if we even follow the correct specification or if this TextIterator should rather be dumped. Also #1039 mentions that the TextIterator should become more performant.

It seems that Flow has the only php implementation available for php6 never released TextIterator.

If we want to improve the TextIterator, for example adjust its documentation and possibly fix the implementation and make it faster, we can dug up the php6 code and let us be inspired by it:

I looked a bit into that supposed TextIterator and what happened to php 6 in general. And there is very little information on the web. And it all seemed to vanish :D

The behaviour of the TextIterator can be inferred from the original php6 code which resides in the experimental/first_unicode_implementation in the php-src repo.

Sadly there are only about 4 meaningless tests like that one: https://github.com/php/php-src/blob/experimental/first_unicode_implementation/ext/unicode/tests/iterator_001.phpt

But there is a little documentation: https://github.com/php/php-src/blob/experimental/first_unicode_implementation/README.UNICODE#L561-L582

And of course one can look into the c code of the TextIterator where there are also nice comments <3:
https://github.com/php/php-src/blob/experimental/first_unicode_implementation/ext/unicode/unicode_iterators.c#L1208-L1248

For real experiments one can actually play with this docker image to see php6 in action: https://github.com/wizaplace/docker-php-6-apache

But we can also just remove it and replace or deprecate the eel helpers String.cropAtWord and String.cropAtSentence which are the only consumers of the TextIterator.

The String.cropAtWord pr #864 already hides a native implementation in the first commit with no dependency on the TextIterator but only a few regex's.