Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106182
MIME-Version: 1.0
References: <CAJW__o0GLjcagzF0ZpEK54yyhkFpgV6tm4p+ihnZvv-dC3YFUQ@mail.gmail.com>
 <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> <e67ff0b8-faba-9423-8ef1-69910eea6520@gmail.com>
 <CAF+90c-6ssx7ZXS34D4mUjE98PSnOqd6RvGuQes+xLhN0r-2rA@mail.gmail.com>
 <CAF+90c9pRX5LWpo=HOyXaHPapsWJn4vB5DCjOXx8JXOF-vmWkA@mail.gmail.com>
 <CAJHtznwRQnd36p1Yk51g5mYyXSeWRpvdMmFWv4d15LKUDHWO1Q@mail.gmail.com>
 <CAF+90c8ZccyA-qAQvMzrKB6WEUQ_ZpX_p=GPjt44-t65xmMCTg@mail.gmail.com>
 <CAJHtznz_u5VsaW+UFAoHwsuUuyB9U+DdKK7iPH1U3MYBxApcQw@mail.gmail.com>
 <CAF+90c-c0WE55zoWiTUWvYyh71LBYAxVoyg1jnJZp+QiDEd4ZQ@mail.gmail.com> <CAJHtznyPnACWqkmsU86bnbcaQDTq7JL07kFgc4RraymnRrE81A@mail.gmail.com>
In-Reply-To: <CAJHtznyPnACWqkmsU86bnbcaQDTq7JL07kFgc4RraymnRrE81A@mail.gmail.com>
Date: Mon, 8 Jul 2019 20:23:49 +0200
Message-ID: <CAF+90c93wuYuNVMkj0C236KQ3kov1CALGES57HnT4Ph_Dk9aMA@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Kalle Sommer Nielsen <kalle@php.net>, 
	Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a45cb6058d2f8c72"
Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a45cb6058d2f8c72
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 8, 2019 at 6:56 PM Zeev Suraski <zeev@php.net> wrote:

>
>
> On Mon, Jul 8, 2019 at 5:37 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>>
>> I'm certainly not a domain expert in RTL languages. I'd be happy to drop
>> hebrev() from this RFC if someone can bring forward a good technical
>> argument as to why these functions are still necessary and where they wo=
uld
>> be used.
>>
>
> I do insist you have it backwards - you need a good technical argument as
> to why these functions should be removed - i.e., what negative value do
> they bring to the table that would be sorted out by their elimitation
> (which could even be "pushing people towards using something that I
> consider better", but even that is not available).  This is key, and went
> completely ignored.
>
> That said:
>
>
>> However, and given your comment here I may have just missed this between
>> other mail, I have not actually seen any technical argument on this topi=
c.
>> The only thing I found was a namedrop of "IBM i" without any explanation=
 of
>> the significance this has for Hebrew text or the hebrev() function
>>
>
> IBM i is not a namedrop at all.  Basically, any platform that has no
> built-in RTL support (IBM i being one of them, there are many more) would
> benefit from hebrev().  As a matter of fact, I just recalled that this is
> even useful under Windows (I used it myself a few months ago and forgot
> about it) - as the Windows shell doesn't render logical Hebrew either.  F=
or
> instance, if you have the following files in C:\somedir:
>
> C:\somedir\=D7=A0=D7=99=D7=A7=D7=99=D7=98=D7=94
> C:\somedir\=D7=A7=D7=90=D7=9C
>
> (that's Nikita and Kalle)
>
> The following script:
> ----
> <?php
> $d =3D opendir("c:\\somedir");
> while ($f =3D readdir($d)) {
>         print "$f\n";
> }
> ---
>
> Would generate the following output:
> https://www.dropbox.com/s/tjs8jwypmy7nvay/Hebrew%20Logical.PNG?dl=3D0
>
> When fixed with hebrev():
> ----
> <?php
> $d =3D opendir("c:\\somedir");
> while ($f =3D readdir($d)) {
>         print hebrev($f)."\n";
> }
> ---
>
> It will display the correct output:
> https://www.dropbox.com/s/wss5fswd9gqj5vk/Hebrew%20Visual.PNG?dl=3D0
>
> I'm *almost* sure that you'd get the same results on Linux.
>
> Simply put - hebrev() is super useful for CLI apps.
>
> The fact it's nowadays thankfully uncommon for HTML to be based on visual
> encodings, doesn't mean visual representations have disappeared.  They're
> still there in all sorts of legacy situations - including legacy scenario=
s
> in modern OSs (the above is from Windows 10 1903).
>

Thanks Zeev, this is exactly the kind of feedback I was looking for. As you
make a case for a possible legitimate use-case, I'm dropping the hebrev()
deprecation from this RFC, so that the proposal only covers hebrevc() now.

(As a side note, it would be great if this kind of information also made it
into the documentation for hebrev().)

Nikita

--000000000000a45cb6058d2f8c72--