Re: [RFC] Unicode Text Processing
| From: | Derick Rethans | Date: | Wed, 21 Dec 2022 11:48:42 +0000 |
| Subject: | Re: [RFC] Unicode Text Processing | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119194@lists.php.net to get a copy of this message | ||
On Fri, 16 Dec 2022, Tim Düsterhus wrote:
> Hi
>
> On 12/16/22 14:55, Derick Rethans wrote:
> > > ----------
> > >
> > > 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
> > :-)
> >
>
> You accidentally put 'startingWithLast' into the 'contains' section.
Oops, fixed.
> 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' …
I've added that as a suggested name too.
> 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?
I guess we can overload the . operator too, but I would still also add
an explicit method.
I've added that to the RFC.
> ----------
>
> 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
- in-between each word.
Indeed, there is no reason why it should be a simple array, and I've
updated the RFC accordingly.
> ----------
>
> 3. Inversely: Should \Text->split() only guarantee 'iterable', instead of
> 'array' as its return type?
That is trickier, as a return value can't be a union. I suppose we could
signal that we return an iterable, but start by always returning an
array. That way if we want to expand this to an actual iterator we can,
without breaking LSP.
Before making that change, I'd like to hear some other opinions on this.
>
> ----------
>
> 4. How is equality comparisons expected to work? Will '==' be overloaded?
> Should users use 'compareWith(…) === 0'? Should an 'equals()' method be
> provided?
'==' will be overloaded. It's mentioned in the ''compareWith''
method.
I have added an equals method, as I think that makes sense.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news
mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug