Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106220
MIME-Version: 1.0
References: <2311901d53767$1c5aa780$550ff680$@gmail.com> <CAJHtznx7u4wKDEjjARCtNd9o-HxCDzd_qERC0Js480sJ+Z9q4A@mail.gmail.com>
In-Reply-To: <CAJHtznx7u4wKDEjjARCtNd9o-HxCDzd_qERC0Js480sJ+Z9q4A@mail.gmail.com>
Date: Tue, 16 Jul 2019 16:34:33 +0200
Message-ID: <CAFPFaMLcMkD9j6km0kSP6O8zgQOO0ZggDxGHgLzrq2wTHMqMfg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000061eeea058dcd47c4"
Subject: Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
From: george.banyard@gmail.com ("G. P. B.")

--00000000000061eeea058dcd47c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 16 Jul 2019 at 16:18, Zeev Suraski <zeev@php.net> wrote:

> Given apparently nobody has paid any attention to this email (both in ter=
ms
> of my support of deprecating hebrevc(), and my request to reconsider
> supporting proposals with substantial numbers of 'nay' voters) - I'm
> resending it one more time for consideration:
>
> On Wed, Jul 10, 2019 at 2:33 PM <zeev@php.net> wrote:
>
> > Two separate topics on this message:
> >
> >
> >
> > First =E2=80=93 I wanted to point out that my fierce defense of the heb=
rev()
> > function does not in fact extend to hebrevc().  As much as I think the
> RFC
> > was really wrong about hebrev(), and we got scarily close to deprecatin=
g
> a
> > functionality that =E2=80=93 while somewhat esoteric =E2=80=93 can be e=
xtremely useful
> > and cannot be easily replicated in any way =E2=80=93 I have to say that=
 I think
> > the RFC is pretty much correct on hebrevc().  I don't think it's very
> > plausible hebrevc() is still in use today =E2=80=93 and even if we're m=
issing
> > something and it is =E2=80=93 it can be implemented in a one liner with=
 100.00%
> > compatibility.  While I don't think it brings much value to deprecate i=
t
> =E2=80=93
> > perhaps sending the message that you shouldn't be using it for HTML bea=
rs
> > *some* level of value.  I voted in favor.
> >
> >
> >
> > Now, with that said =E2=80=93 I would *really* encourage everyone who v=
oted on
> > this RFC (as well as ones who haven't) to take a look at what I would
> call
> > the 'contentious votes' in there.  In a nutshell, votes with a
> substantial
> > amount of people voting against the deprecation.  If you voted 'yes' fo=
r
> > one of these =E2=80=93 please consider, for a moment, whether your posi=
tion on it
> > is "It's evil, I really think we're better off without it" or whether
> it's
> > more of a "I don't think it's very useful".   If it's the former =E2=80=
=93 by all
> > means, keep your vote.  But if it's the latter =E2=80=93 please conside=
r the
> > possibility that the fact that a substantial number of people feel
> strongly
> > enough about keeping it to vote against the deprecation (and let's admi=
t
> it
> > =E2=80=93 against the odds), may mean it is, in fact, useful =E2=80=93 =
even if you don't
> > find it useful yourself.
> >
> >
> >
> > While we can argue whether consensus-based voting makes sense for votes
> in
> > general, I think it's tenfold more important when dealing with
> > deprecations.  If there's a substantial minority that thinks a feature =
is
> > still useful =E2=80=93 we should keep it =E2=80=93 unless there's a rea=
l tangible cost
> > associated with keeping it.  For most of the proposed deprecations =E2=
=80=93 that
> > cost is simply not there.
> >
> >
> >
> > For reference, this is what consensus looks like:
> >
> > https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=3D0
> >
> > https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=3D0
> >
> >
> >
> > And this is what it doesn't look like:
> >
> > https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=3D0
> >
> > https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=3D0
> >
> >
> >
> > To connect with the first point =E2=80=93 the hebrevc() vote certainly =
looks a
> > lot more like the latter than the former, but I do believe it's mostly
> > related to confusion with hebrev() and as the author of both =E2=80=93 =
I feel
> > comfortable supporting its removal :)
> >
> >
> >
> > Thanks for your consideration,
> >
> >
> >
> > Zeev
> >
>

Hello Zeev,

First of all it seems that you've mixed up your consensus2 and no-consesus2
files as they currently show the opposite of what you want to convey, I
think.

Secondly the word you are looking for here is "unanimity"/"unanimous" as
per the Cambridge dictionary [1]:

> *If a group of people are unanimous, they all agree about one particular
> matter or vote the same way, and if a decision or judgment is unanimous, =
it
> is formed or supported by everyone in a group*


As consensus means, also from the Cambridge dictionary [2]:

> *a generally accepted opinion or decision among a group of people*
>

Now unanimity implies consensus however not having a unanimous vote does
not mean there is no consensus.
Moreover, even though "consensus" does come from the Latin *c=C5=8Dns=C4=93=
nsus*
(=E2=80=9Cagreement,
accordance, unanimity=E2=80=9D) [3] it does not require unanimity IMHO.

The RFC process establishes a consensus when 2/3 of the voters agree, which
is currently the case.
An argument could be made that this isn't a large enough consensus -
something I don't agree with - however, at the time of writing this, all
the deprecations even pass a 3/4 consensus [4].

Best regards

George P. Banyard

[1] https://dictionary.cambridge.org/dictionary/english/unanimous
[2] https://dictionary.cambridge.org/dictionary/english/consensus
[3] https://en.wiktionary.org/wiki/consensus
[4] https://php-rfc-watch.beberlei.de/

--00000000000061eeea058dcd47c4--