Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85462
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5512AB8B.4020409@gmail.com>
References: <CAF+90c-CbGZ1d3DJSbzPmCbpjm6Pw3qPXQ=CG4XvbaM+528+jQ@mail.gmail.com>
	<006301d06637$ebbb4ee0$c331eca0$@php.net>
	<BLU436-SMTP34001F28C093D64F89F882E20A0@phx.gbl>
	<007901d0664f$dee34430$9ca9cc90$@php.net>
	<55119F4E.6010503@gmail.com>
	<CAFMT4Nos6Hm3pGf-av5zfun_GBMSX+y5f14B6d=c9U-8YvybbQ@mail.gmail.com>
	<5512AB8B.4020409@gmail.com>
Date: Wed, 25 Mar 2015 14:19:01 +0100
Message-ID: <CAEZPtU7hKBaLy_7-O2r-1QR5wWtX+=2wA+cF3UWmeRf8CY1GvA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Mar 25, 2015 at 1:35 PM, Rowan Collins <rowan.collins@gmail.com> wr=
ote:
> Levi Morrison wrote on 24/03/2015 20:35:
>
>> On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins <rowan.collins@gmail.com=
>
>> wrote:
>>>
>>> Fran=C3=A7ois Laupretre wrote on 24/03/2015 16:30:
>>>>>
>>>>> De : Bob Weinand [mailto:bobwei9@hotmail.com]
>>>>>
>>>>> No, he isn't asking for delaying the timeline. He's asking if we can =
do
>>>>> this
>>>>> without RFC. Minimal self-contained changes don't need a RFC and can =
go
>>>>> as
>>>>> well into alpha/beta phase without issues.
>>>>
>>>> Sorry, I don't understand when a change is supposed to require an RFC =
or
>>>> not, and when it can come after feature freeze or not. Is it written
>>>> somewhere ? What is the definition of a 'minimal self-contained' chang=
e
>>>> ?
>>>> Why is it different if it belongs to an extension ?
>>>>
>>>> I may be wrong but the proposed change is not what I call a 'minimal
>>>> self-contained' change and there's a clear BC break. I'd love it to be
>>>> part
>>>> of 7.0 but I would first appreciate to be sure the rules are the same
>>>> for
>>>> everyone.
>>>
>>>
>>> Agreed, this is quite a major feature, and pretty much everything in PH=
P
>>> is
>>> an "extension" as far as the architecture is concerned.
>>>
>>> While I agree it would be great to phase this functionality out, I don'=
t
>>> see
>>> how that can be done without an RFC.
>>
>> If we deprecate it I am fine with doing this without an RFC. Removing
>> it would need an RFC in my opinion.
>
>
> But a decision to "deprecate" just means "remove, but not yet", so either
> way we're making a decision about what features the language will have, a=
nd
> skipping the established process in the name of convenience.
>
> I wonder if people are confusing the fact that they don't like this featu=
re,
> and don't need it, with it being a "minor" feature. There are definitely
> people out there using it, and the impact of removing it may be considera=
ble
> to them. There is also the question of what we are deprecating it in favo=
ur
> of.

To me it is buggy. It is a partial implementation to begin with. An
app has no idea what is supported or not, custom extensions will call
native APIs without taking care about what the PHP exposed functions
are.

> Remember that it's perfectly acceptable to deprecate something in a minor
> release, so if by the time of 7.1 or 7.2 a new way of working with Unicod=
e
> or character set aware strings is taking shape, we could deprecate in fav=
our
> of that.
>
> Or, if we think that the costs of including the feature are too great, an=
d
> forcing use of mb_* functions directly is appropriate, we can deprecate i=
n
> 7.1, presumably waiting until 8.0 to make the breaking change of removal.

That's  the way to go, to use mb_* directly or even better, ICU related API=
s.

> Once again, the decisions taken are that there is no 5.7 for deprecation,
> and no more RFCs allowed for 7.0 anyway. If we're going to stick to those
> decisions, we have to accept that ideas we come up with now will have to
> wait until 7.1 (next year) or 8.0 (4 to 5 years time).

I think we will have more of these cases, and some without consensus.
We chose not to have 5.7, so be it.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org