Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106025
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=wXAaqiorBDDSpWAe8NMP1SRwAVh8glAiiRuEbG7N6nKNaWYYwzA9FvL/6bMgxy
	ZBGThgq2kGZMAt/LogVoUYvFOPHRL2Npri8ru84/+ARaIqsku+32XFcBwxtXP1G5
	eh+lpu/g1WPTpmqPbh2GAgEspAqRSAiGM+FTNuAcGdPhk=;
MIME-Version: 1.0
References: <CAJW__o0GLjcagzF0ZpEK54yyhkFpgV6tm4p+ihnZvv-dC3YFUQ@mail.gmail.com> <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> <CAJW__o1pFnhtvyX5prNFV--PWNdb3deopwky1aRzY-bPuuA9bQ@mail.gmail.com>
In-Reply-To: <CAJW__o1pFnhtvyX5prNFV--PWNdb3deopwky1aRzY-bPuuA9bQ@mail.gmail.com>
Date: Sat, 22 Jun 2019 13:43:46 +0300
Message-ID: <CAJHtznzgUWbXQrd85h+yQbHGo3SoME8gvKJaq-MvEOW=5h42jQ@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Internals <internals@lists.php.net>,  Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000981448058be74113"
Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4
From: zeev@php.net (Zeev Suraski)

--000000000000981448058be74113
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 22, 2019 at 10:23 AM Kalle Sommer Nielsen <kalle@php.net> wrote=
:

> Hi
> Den l=C3=B8r. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalyshev@gmail.com>:
> > My first question for many of those is - why? I.e. it deprecates a bunc=
h
> > of niche functions. Most people do not use these functions, so they
> > probably don't care. Those they do use them would find their code broke=
n
> > or produce new warnings and needs to be changed. I have hard time
> > identifying whose life would be made better by these changes.
> >
> > Now, if some of these functions are hopelessly broken or have no valid
> > use cases - like magic quotes - then phasing them out makes sense, and
> > the audience whose life can be made better are people who use those
> > unaware of them being broken, or plan to use them and would thus have
> > broken code unless we warn them (or remove the functions, eventually).
> >
> > But for functions that work just fine, I see absolutely no reason to
> > introduce friction without any apparent upside.
>
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
>

Kalle,

I see very few ways in which you'd be able to convince anybody whose code
was impacted by these removals that they're better off having to audit
their code and learn new library semantics - instead of, well, doing
nothing.

I view this in the same trend as the deprecation of short_tags -
deprecations that may make us feel good, make for a 'more proper' code
base, and bring hassle to our userbase while aiding absolutely no-one in
the process.


> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
>

Simple - it harms nobody to keep it, and removing it aids nobody.


> hebrev(), hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support <html dir=3D"rtl"
> lang=3D"he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
>

I've seen hebrev() used as recently as a couple of years ago and given that
I'm not very active in the local community - it's probably still being used
in all sorts of use cases when interacting with old legacy systems (e.g.
IBM i).  How are you assuming it's not in use?

One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere.


While I've heard the former complaint very frequently (and I agree with it
entirely), I've quite literally *never* heard the latter complaint.  Not
once.  Niche functionality doesn't bug anybody.  Inconsistent core
functionality bugs mostly everyone.  Bundling the two as if they're the
same, or even similar - is wrong.  Niche functionality isn't in the way of
anybody - and while it's mostly of no use for most people, the few people
who do need it would often be remarkably thankful for finding it available
(hebrev() certainly falls in that category).  These functions have zero
negative footprint - they consume virtually no memory, they don't slow
anything down, and I'd feel very confident arguring they do not pollute the
namespace in any meaningful way (if anybody here ever bumped into someone
that was upset about hebrev() being taken, please raise your hand).

Instead of removing functionality that most find useless but some found
invaluable - why don't we introduce a new extension, 'legacy', that will
include these functions?  It can even be disabled by default.  That way we
don't needlessly and pointlessly make the upgrade path more difficult - or
at least, we make it just marginally so (you'd be able to eliminate a class
of needless compatibility breakages that would otherwise send you auditing
and researching new ways to do exactly the same thing - by simply turning
on an extension).

I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
>
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
>

Again, I think our standard library certainly suffers from defficiencies -
but I have a hard time accepting that niche functions is anywhere near the
top of that list, or that it's even on it to begin with.

The key problems of our standard libraries are inconsistencies in naming,
inconsistencies in argument definitions and sometimes inconsistencies in
behavior.

Personally, I think we should actually consider tackling these with a newly
designed standard library that would be available via a new top level
namespace - *without* interfering with the existing one - which perhaps we
can then deprecate by 2030.  That would actually bring tremendous value to
end users, unlike some of these deprecations.

To summarize:
1.  Reconsider the proposal to deprecate useful (albeit niche) functions
like convert_cyr_string(), hebrev(), money_format() and others..  These
deprecations bring virtually zero value but very non-zero headache to
affected users.   I've yet to bump into a single person, ever, that told me
how happy they were with version X.Y deprecating feature Z. Complaints?
That's a different story.
2.  In case you do want to move forward with them - consider moving them to
a new 'legacy' extension instead of outright removing them.  Perhaps this
can be a solution for short_tags as well, and it can also be a longer-term
compromise between the motivation to 'clean up' the language, and the
hassle it inflicts on our users when they want to upgrade (which results in
longer upgrade cycles and consequently worse security overall).
3.  I think we'd all be better off focusing on the real deffficiencies of
our standard library.  Deprecating's easy, but it's also not very useful.
If we can introduce a new, fixed standard library in PHP 8 - it can be a
game changer.

Thanks,

Zeev

--000000000000981448058be74113--