Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119195
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl>
 <f1ad71e1-dadd-f194-7eb9-68a746792c08@gmail.com> <alpine.DEB.2.23.453.2212161329110.462551@singlemalt.home.derickrethans.nl>
 <CALKiJKr2OyfkLbF6ugDTqztpZED-NgqnkPJPgUoqLc5SBmkCJg@mail.gmail.com> <alpine.DEB.2.23.453.2212211121590.462551@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2212211121590.462551@singlemalt.home.derickrethans.nl>
Date: Wed, 21 Dec 2022 15:51:18 +0000
Message-ID: <CALKiJKrJ85a5AC9sXtHyjayRkCN3ec=-HqbXa2n5aOumRE7PpQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a585b305f05886c9"
Subject: Re: [PHP-DEV] [RFC] Unicode Text Processing
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000a585b305f05886c9
Content-Type: text/plain; charset="UTF-8"

On Wed, 21 Dec 2022 at 11:48, Derick Rethans <derick@php.net> wrote:

> I know what a polyfill is, and I still don't want to see this.
>


I can 100% guarantee that you will *see* it - as soon as this RFC is even
close to being accepted, either the Symfony project or someone else will
work on such a polyfill. But if you're not interested in *writing* it,
that's fair enough.



> I know what it would entail, but I am rejecting it regardless. "Just an
> optional argument on a couple of methods" increases the complexity.
>


Complexity can cut both ways: from the point of view of the user, this...

$value = new Text( UConverter::transcode($utf16_value, 'UTF-8', 'UTF-16BE')
);
// ...
echo UConverter::transcode((string)$value,  'UTF-16BE' , 'UTF-8');

...is significantly more complex than this:

$value = new Text($utf16_value, 'UTF-16BE');
// ...
echo $value->asBytes('UTF-16BE');

An additional problem with the long version is that UConverter is only
available if ext/intl is enabled (mb_convert_encoding is an alternative,
with the same problem) - something which was discussed at length when I
proposed removal of utf8_encode and utf8_decode.



> That sounds like an argument for having a sort() method where you can
> override the collator. I would however expect that most people would not
> set a default collation other than "standard" on Text objects though.
> And if something more clever needs to be done, this can be overridden in
> all methods.
>


In this case, I think I'm arguing from the same angle as you are on
encodings - if setting a per-object default collator is a rare action, and
not generally useful, let's eliminate the complexity of supporting it, and
just leave the method arguments.



> Yes, and that is why the RFC includes a ''TextCollator'' object that
> does precisely that.



Indeed; I think mostly what I'm saying is that users should always look at
the object first, and the string format only if they really need it.

Specifically, the current proposal lists parameters as "string $collation"
implying this:

// strings can be passed directly
$a->compareWith($b, 'en-u-ks-level1');
// object is only a way of creating the string
$a->compareWith($b, (new
TextCollator('en'))->setCaseInsensitive()->getCollationString() );

I'm proposing instead that they be "TextCollator $collation", implying this:

// object is the normal argument
$a->compareWith($b, (new TextCollator('en'))->setCaseInsensitive());
// strings are only a way of getting an object
$a->compareWith($b, TextCollator::fromCollationString('en-u-ks-level1'));

A third option would be to make the parameters a union "TextCollator|string
$collation", implying this:

// object is supported directly
$a->compareWith($b, (new TextCollator('en'))->setCaseInsensitive());
// so are strings if you already have one for some reason
$a->compareWith($b, 'en-u-ks-level1');

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000a585b305f05886c9--