Re: [RFC] Unicode Text Processing
| From: | Tim Düsterhus | Date: | Fri, 16 Dec 2022 15:44:53 +0000 |
| Subject: | Re: [RFC] Unicode Text Processing | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119177@lists.php.net to get a copy of this message | ||
Hi
On 12/16/22 14:55, Derick Rethans wrote:
You accidentally put 'startingWithLast' into the 'contains' section. But thinking about the name a little more: 'At' instead of 'With' might be a little more appropriate, because $a->startingWith($b) could also mean '$b . $a' … which brings me to: ---------- 1. How is concatenation expected to work? Will '.' be overloaded or should folks use: \Text::join([ $prefix, '-' $suffix, ], ''); or similar? Perhaps an explicit \Text::concat(…) method should be provided? ---------- 2. As I've noted in the discussion for List\unique: I think iterators should not be second-class citizen to arrays. Thus I propose to change \Text::join() to: /** @param iterable<\Text|string> $elements */ public static function join(iterable $elements, \Text|string $separator, string $collator = null): \Text This would then allow stuff like: Text::join($someText->getWordIterator(), '-') to insert---------- getPositionOfFirstOccurrence(): I agree this is too long. How about: - findOffset() - findOffsetLast() And for returnFromFirstOccurence(): - startingWith() - startingWithLast()I have included these as suggested names. I suspect we'll get more :-)
- in-between each word.
----------
3. Inversely: Should \Text->split() only guarantee 'iterable', instead of 'array' as its return type?
----------
4. How is equality comparisons expected to work? Will '==' be overloaded? Should users use 'compareWith(…) === 0'? Should an 'equals()' method be provided?
----------
Best regards
Tim Düsterhus