Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics

This is only part of a thread. view whole thread
  106180
July 8, 2019 16:56 zeev@php.net (Zeev Suraski)
On Mon, Jul 8, 2019 at 5:37 PM Nikita Popov 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 would > 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 topic.. > 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. For instance, if you have the following files in C:\somedir: C:\somedir\ניקיטה C:\somedir\קאל (that's Nikita and Kalle) The following script: ---- https://www.dropbox.com/s/tjs8jwypmy7nvay/Hebrew%20Logical.PNG?dl=0 When fixed with hebrev(): ---- https://www.dropbox.com/s/wss5fswd9gqj5vk/Hebrew%20Visual.PNG?dl=0 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 scenarios in modern OSs (the above is from Windows 10 1903). (To be clear: I'm not interested in whether it's still used, I'm interested
> whether it's still used *for good reason*.) >
If it's still being used, it's almost definitely being used for a good reason. Nobody uses hebrev() to knock themselves out or because they take some sort of perverted pleasure out of it. They use it because they have to. And what you're proposing is taking that capability away, providing zero workarounds, and gaining absolutely nothing in the process. Why? Zeev
  106182
July 8, 2019 18:23 nikita.ppv@gmail.com (Nikita Popov)
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 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 would >> 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 topic. >> 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. For > instance, if you have the following files in C:\somedir: > > C:\somedir\ניקיטה > C:\somedir\קאל > > (that's Nikita and Kalle) > > The following script: > ---- > $d = opendir("c:\\somedir"); > while ($f = readdir($d)) { > print "$f\n"; > } > --- > > Would generate the following output: > https://www.dropbox.com/s/tjs8jwypmy7nvay/Hebrew%20Logical.PNG?dl=0 > > When fixed with hebrev(): > ---- > $d = opendir("c:\\somedir"); > while ($f = readdir($d)) { > print hebrev($f)."\n"; > } > --- > > It will display the correct output: > https://www.dropbox.com/s/wss5fswd9gqj5vk/Hebrew%20Visual.PNG?dl=0 > > 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 scenarios > 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