Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106291
MIME-Version: 1.0
References: <2311901d53767$1c5aa780$550ff680$@gmail.com> <CAJHtznx7u4wKDEjjARCtNd9o-HxCDzd_qERC0Js480sJ+Z9q4A@mail.gmail.com>
 <CAFPFaMLcMkD9j6km0kSP6O8zgQOO0ZggDxGHgLzrq2wTHMqMfg@mail.gmail.com>
 <CAJHtznzFkBaTYPx2XXLpvpHxExRarqmi9_i4NxBCK4UeugqUyw@mail.gmail.com> <bfea81cc6f2dfde6bb1869f27f491156426e957d.camel@schlueters.de>
In-Reply-To: <bfea81cc6f2dfde6bb1869f27f491156426e957d.camel@schlueters.de>
Date: Thu, 25 Jul 2019 13:23:17 +0100
Message-ID: <CALKiJKq4-0L2D+YHM9qdFB9kqunhBHEg5=0ThasWQv603HZ+2g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004202f2058e807e09"
Subject: Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
From: rowan.collins@gmail.com (Rowan Collins)

--0000000000004202f2058e807e09
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 23 Jul 2019 at 12:12, Johannes Schl=C3=BCter <johannes@schlueters.d=
e>
wrote:

> A good reading on consensus in technical discussions is this:
> https://tools.ietf.org/html/rfc7282



I just skimmed that document, and I think there's a lot we could learn from
it, if we had the confidence to truly reform.

You could pretty much replace "IETF" with "PHP" in this paragraph, and
you'd have a summary of why we *shouldn't* rely on votes as much as we do:

>  We don't vote in the IETF.  In some ways, we can't vote: Since the
>  IETF is not a membership organization, it's nearly impossible to
>   figure out who would get a vote for any given question.  We can't
>   know who the "members" of any given working group would be at any one
>   time, and we certainly can't know who all of the "members" of the
>   IETF would be: That's why we refer to "participants" in the IETF; the
>   IETF doesn't really have "members".





> On hebrev()/hebrevc(): I believe most contributors have no idea what it
> does and I for one have no need. It doesn't hurt me, though. As long as
> it works for the users I'd keep it since cost is low. If I'd support
> adding such a function in future is a different question.
>


I agree with everyone who has said removing a feature (and every
"deprecation" is actually a proposal to remove something) should have a
much higher bar than not adding it.

I think there is also an extra requirement that removal (and therefore
deprecation) should have, which many of these proposals *also* don't pass:
what should people be using instead? To me, every deprecation note should
be able to clearly say one of two things:
- If you are using this feature, You Are Wrong. Don't do it, emulate it
only as a short-term measure, work to remove it.
- If you are using this feature, you should use this specific feature
instead, because it is better in these ways.

Take convert_cyr_string, for example. The RFC says "one of
mb_convert_encoding(), iconv() or UConverter may be used for this purpose".
There's a sleight of hand here - it sounds like we've offered the user an
upgrade path, but we haven't actually said *how* to get the equivalent
functionality. Why are there three options, all in different optional
extensions? Will one of them be removed in a few years' time, leaving users
to fix their code all over again? What options does each of these need to
emulate the old function? Is it even possible, or will there be subtle
differences that need testing?

If the aim is to have a Right Way to do everything, we should be saying
what that Right Way is.

I picked this example in particular, because I'd actually love there to be
better guidance on how to convert encodings, and I'd like to remove
utf8_encode and utf8_decode, which I think cause far more damage by being
so badly named. I haven't proposed it, because for the people who are using
those functions correctly, there would need to be a clear replacement, and
right now there isn't.

Regards,
--=20
Rowan Collins
[IMSoP]

--0000000000004202f2058e807e09--