Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106023
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 09:44:25 +0200
Message-ID: <CAOwTYAtMhNw2-n7X_NUEXOY0UR2m7ijUVbS28Uy4S+i1hS4fXw@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="0000000000002ea39b058be4c02d"
Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4
From: krakjoe@gmail.com (Joe Watkins)

--0000000000002ea39b058be4c02d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just a note on process.

It is not necessary to hold multiple RFC's:

> For procedural reasons, multiple RFCs may be combined into one, in which
case there may be multiple primary votes.
> Combining multiple RFCs into one does not allow turning a primary vote
into a secondary vote.

In general, something is considered a primary vote if it could be conducted
independently of other primary votes in the same RFC - ie, it is not an
implementation detail.

So, what we have here is multiple primary votes ...

[1] https://wiki.php.net/rfc/voting

Cheers
Joe



On Sat, 22 Jun 2019 at 09:23, 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:
>
> 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?
>
> 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?
>
> 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. 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.
>
> > For the specifics, I think things like removing allow_url_include
> > requires separate RFC. It's a serious functionality change, and bundlin=
g
> > it with 20 or so other changes would not allow to properly consider it.
> > In general mass-change RFCs usually are not very conductive to properly
> > discussing each specific change, but mixing changes of different types
> > makes it even worse.
>
> I will have a chat with Nikita regarding this.
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> kalle@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0000000000002ea39b058be4c02d--