hebrevc() and other 'contentious' 7.4 proposed deprecations View as Markdown

Two separate topics on this message:

First - I wanted to point out that my fierce defense of the hebrev()
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 deprecating a
functionality that - while somewhat esoteric - can be extremely useful and
cannot be easily replicated in any way - 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 - and even if we're missing something and it
is - it can be implemented in a one liner with 100.00% compatibility. While
I don't think it brings much value to deprecate it - perhaps sending the
message that you shouldn't be using it for HTML bears some level of value.
I voted in favor.

Now, with that said - I would really encourage everyone who voted 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' for one
of these - please consider, for a moment, whether your position 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 - by all means,
keep your vote. But if it's the latter - please consider 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 admit it - against the
odds), may mean it is, in fact, useful - 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 - we
should keep it - unless there's a real tangible cost associated with keeping
it. For most of the proposed deprecations - that cost is simply not there.

For reference, this is what consensus looks like:

https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0

https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0

And this is what it doesn't look like:

https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0

https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0

To connect with the first point - 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 - I feel comfortable
supporting its removal :)

Thanks for your consideration,

Zeev

Given apparently nobody has paid any attention to this email (both in terms
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:

Two separate topics on this message:

First – I wanted to point out that my fierce defense of the hebrev()
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 deprecating a
functionality that – while somewhat esoteric – can be extremely useful
and cannot be easily replicated in any way – 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 – and even if we're missing
something and it is – it can be implemented in a one liner with 100.00%
compatibility. While I don't think it brings much value to deprecate it –
perhaps sending the message that you shouldn't be using it for HTML bears
some level of value. I voted in favor.

Now, with that said – I would really encourage everyone who voted 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' for
one of these – please consider, for a moment, whether your position 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 – by all
means, keep your vote. But if it's the latter – please consider 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 admit it
– against the odds), may mean it is, in fact, useful – 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 – we should keep it – unless there's a real tangible cost
associated with keeping it. For most of the proposed deprecations – that
cost is simply not there.

For reference, this is what consensus looks like:

https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0

https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0

And this is what it doesn't look like:

https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0

https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0

To connect with the first point – 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 – I feel
comfortable supporting its removal :)

Thanks for your consideration,

Zeev

Given apparently nobody has paid any attention to this email (both in terms
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:

Two separate topics on this message:

First – I wanted to point out that my fierce defense of the hebrev()
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 deprecating
a
functionality that – while somewhat esoteric – can be extremely useful
and cannot be easily replicated in any way – 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 – and even if we're missing
something and it is – it can be implemented in a one liner with 100.00%
compatibility. While I don't think it brings much value to deprecate it
–
perhaps sending the message that you shouldn't be using it for HTML bears
some level of value. I voted in favor.

Now, with that said – I would really encourage everyone who voted 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' for
one of these – please consider, for a moment, whether your position 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 – by all
means, keep your vote. But if it's the latter – please consider 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 admit
it
– against the odds), may mean it is, in fact, useful – 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 – we should keep it – unless there's a real tangible cost
associated with keeping it. For most of the proposed deprecations – that
cost is simply not there.

For reference, this is what consensus looks like:

https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0

https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0

And this is what it doesn't look like:

https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0

https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0

To connect with the first point – 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 – 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ōnsēnsus
(“agreement,
accordance, unanimity”) [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/

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ōnsēnsus (“agreement,
accordance, unanimity”) [3] it does not require unanimity IMHO.

While there are different definitions for consensus - as you point out
yourself, one of the definitions is certainly a synonym for uninamity - and
that's how I personally found it commonly used throughout my life.
Regardless, it certainly implies no strong disagreement from those in the
minority - which is not the case here.

The RFC process establishes a consensus when 2/3 of the voters agree,
which is currently the case.

As the author of that RFC, I can tell you with complete confidence that
deprecations were not in the intended scope of that process. It's quite
evident from the language of the Voting RFC itself:

"Given that changes to languages (as opposed to changes to apps or even
frameworks) are for the most part irreversible - the purpose of the vote is
to ensure that there's strong support for the proposed feature."

If the bar to remove a feature is identical to introducing it - it's hardly
irreversible. The current behavior was never ever intended. It wasn't
even supposed to be used for deprecations - but for new features.

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].

I think there are at least two issues that in a healthy environment would
be needed:

• A clear, tangible benefit to the deprecation. Having another way of
  doing something certainly does not constitute a clear, tangible benefit to
  removing a feature. This should be a pre-requisite for a deprecation. In
  the past it was an obvious, implicit requirement - but that's from the days
  where we weren't as 'litigative', so it may make sense to explicitly point
  it out for the future.
• A much stronger consensus, that prevents the tyranny of the majority in
  such cases. Whether it should be 100% or 95% - but it certainly shouldn't
  be 2/3 or even 3/4 - and should put into affect the notion that 'changes to
  the language are for the most part irreversible' - which was a fundamental
  tenet of the Voting RFC.

Zeev

The RFC process establishes a consensus when 2/3 of the voters agree,
which is currently the case.

As the author of that RFC, I can tell you with complete confidence that
deprecations were not in the intended scope of that process. It's quite
evident from the language of the Voting RFC itself:

"Given that changes to languages (as opposed to changes to apps or even
frameworks) are for the most part irreversible - the purpose of the vote is
to ensure that there's strong support for the proposed feature."

If the bar to remove a feature is identical to introducing it - it's
hardly irreversible. The current behavior was never ever intended. It
wasn't even supposed to be used for deprecations - but for new features.

It seems this mention has been removed after the amendment from the
"Abolish Narrow Margin" RFC, and I'm also seeing that there hasn't been any
amendment made to the document after the "Abolish Short Votes" RFC passed".

I personally don't see the problem of having deprecation with the same
threshold as feature for voting, which is only mandatory since the Narrow
Margin RFC came into effect, but this is only my opinion.
If you feel that strong about correcting this issue you could make an RFC
to amend the Voting RFC/Process, like Joe did (twice), to add a special
case for feature deprecation. And no I don't think the voting process need
a complete revamp.

Also, I just want to point out that, IMHO, the main reason for the high
amount of deprecations for PHP 7.4 is that it is the last minor version
before the next major. And who know how long it is going to take to have
the next major (supposedly 5 years) which is a long time in tech.

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].

I think there are at least two issues that in a healthy environment would
be needed:

• A clear, tangible benefit to the deprecation. Having another way of
  doing something certainly does not constitute a clear, tangible benefit to
  removing a feature. This should be a pre-requisite for a deprecation. In
  the past it was an obvious, implicit requirement - but that's from the days
  where we weren't as 'litigative', so it may make sense to explicitly point
  it out for the future.

This ties in to the point above about making an amendment to the Voting
process.

• A much stronger consensus, that prevents the tyranny of the majority in
  such cases. Whether it should be 100% or 95% - but it certainly shouldn't
  be 2/3 or even 3/4 - and should put into affect the notion that 'changes to
  the language are for the most part irreversible' - which was a fundamental
  tenet of the Voting RFC.

Zeev

These thresholds are, in my mind, pure insanity.
Let's run some numbers on how little people do you need to make a vote fail
with 95% (because 100% is always 1):
10 voters: 1 person (need 9.5 voters in favour),
15 voters: 1 person (need 14.25 voters in favour) ,
20 voters: 2 people (need 19 voters in favour) ,
25 voters: 2 people (need 23.75 voters in favour) ,
30 voters: 2 people (need 28.5 voters in favour, which is usually how many
people vote for "normal" RFC from what I see
35 voters: 2 people (need 33.25 voters in favour)
40 voters: 3 people (need 38 voters in favour) about the number of people
currently voting on the PHP 7.4 deprecations RFC
45 voters: 3 people (need 42.75 voters in favour)
50 voters: 3 people (need 47.5 voters in favour)
55 voters: 3 people (need 52.25 voters in favour) high profile RFCs
60 voters: 4 people (need 57 voters in favour)
65 voters: 4 people (need 61.75 voters in favour)
70 voters: 4 people (need 66.5 voters in favour) Typed property V2 RFC
(super high profile RFC)
75 voters: 4 people (need 71.25 voters in favour)
80 voters: 5 people (need 76 voters in favour)

This is madness: to make a vote fail you just need to find, with current
voting turnout, 2 other people to make a vote fail.
Sure it is possible for a tyranny of the majority but with these threshold
there is also clearly a tyranny of a minority because 56 voters in favour
and 3 against is IMHO a clear statement of consensus but would fail with a
95% majority.
And I don't think a 90% threshold is that much better. I think the highest
threshold I would possibly go with high discomfort is 80% (4/5).

I know that you're aren't necessarily keen on having so many people able to
vote, which is the opposite of what I believe as I think the more people
vote the better and more reflective of a vote we get.
That's why we are always going to end in disagreement about these things
IMO as we have opposite philosophies.

Side note: I replied to you resending this email is to let you know that at
least someone has read it -even before the resend - however I don't think
I'm the only one who's read it and didn't reply.

Best regards

George P. Banyard

On Tue, Jul 16, 2019 at 7:34 AM G. P. B. george.banyard@gmail.com
wrote:

The RFC process establishes a consensus when 2/3 of the voters agree,
which is currently the case.

As the author of that RFC, I can tell you with complete confidence that
deprecations were not in the intended scope of that process. It's quite
evident from the language of the Voting RFC itself:

"Given that changes to languages (as opposed to changes to apps or even
frameworks) are for the most part irreversible - the purpose of the vote
is
to ensure that there's strong support for the proposed feature."

If the bar to remove a feature is identical to introducing it - it's
hardly irreversible. The current behavior was never ever intended. It
wasn't even supposed to be used for deprecations - but for new features.

It seems this mention has been removed after the amendment from the
"Abolish Narrow Margin" RFC,

True, I think it's an unfortunate side-effect of the somewhat hasty process
that surrounded that amendment. It's completely clear from the background
of the 'Abolish' RFC that the gripe was with the fact that there was
differentiation between language features and non-language features, and
not with the rationale for the need for a high bar. In the process, the
rationale for having a strong majority (as opposed to having a regular
50%+1 majority) was entirely lost, which is unfortunate - but obviously
does not change in any way the rationale itself.

Also, I just want to point out that, IMHO, the main reason for the high
amount of deprecations for PHP 7.4 is that it is the last minor version
before the next major. And who know how long it is going to take to have
the next major (supposedly 5 years) which is a long time in tech.

I agree - but I still fail to see that as a reason to deprecate things
which are harmless (or that in other words - provide no tangible value upon
removal). There are things on that list that would likely do no harm even
if they existed in PHP 20.0.

These thresholds are, in my mind, pure insanity.

...
This is madness: to make a vote fail you just need to find, with current
voting turnout, 2 other people to make a vote fail.
Sure it is possible for a tyranny of the majority but with these threshold
there is also clearly a tyranny of a minority because 56 voters in favour
and 3 against is IMHO a clear statement of consensus but would fail with a
95% majority.
And I don't think a 90% threshold is that much better. I think the highest
threshold I would possibly go with high discomfort is 80% (4/5).

It's not madness at all. Deprecations need a strong, non-partisan case to
be enacted. A lot of the deprecations on the current RFC simply do not
have that. Others do, and you can easily tell the difference between them

• consensus (or uninamity), vs. not. So it's clear that for good, valid
  deprecations - getting that 95% or even 100% uninamity is easy.

The reality is that right now, the PHP project somehow became
deprecation-oriented, and lost its long established guideline of bias for
downwards compatibility.
I'm absolutely positive that folks that voted in favour of deprecations
have thought less about the implications of their votes compared to folks
who voted against. It's simply easy to go with the flow, join the majority

• without understanding the details I'd go as far as saying that had the
  other half of originally proposed deprecations stayed on the ballot - many
  of them would also clear - quite easily - the 2/3 bar - because of the
  pro-deprecation sentiment that currently exists on internals. We just have
  to be thankful that Nikita and Kalle were responsible to remove them ahead
  of time - I just wish they did the same thing with a few of the other ones.

The solution may be to somehow 'bucketize' the deprecations, as
security-related, maintenance-related or cleanliness-related (maybe there
are other categories). Security related are probably fine with 2/3.
Maintenance related (i.e. if there's no maintainer for a certain extension)
may not even require a vote at all (but are probably fine with regular
votes). It's the 'style' ones which are IMHO unacceptable for 2/3. In
other words, without a tangible benefit - a deprecation proposal should
either not be proposed at all, or should clear a virtually unanimous
threshold to be enacted.

Zeev

Hi!

The reality is that right now, the PHP project somehow became
deprecation-oriented, and lost its long established guideline of bias for
downwards compatibility.

Hear, hear! I am positively astonished at so many RFCs trying to
deprecate so many functions in PHP. Who does it help? Who did those
functions hurt? I understand when we're deprecating something that does
not work or has too many broken uses to use it right, etc. Sometimes we
recognize we made a mistake and have to get rid of it (magic quotes!).
But doing it just to "reduce the size of standard library" looks to me
completely contrary to what PHP has always been about - going extra mile
to make it easier for the user, even at the cost of redundancy. We're
not one of those slick code golf languages where you can write witty
one-liners that do something you won't remember next morning. We aim for
people that actually do work with the language. Which means, we provide
them with tools handy for various tasks, and we are very conservative in
breaking their code - only as the last resort.
So I must say I'm rather disappointed with the zeal people are voting
for removing functions that hurt nobody.

--
Stas Malyshev
smalyshev@gmail.com

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ōnsēnsus (“agreement,
accordance, unanimity”) [3] it does not require unanimity IMHO.

While there are different definitions for consensus - as you point
out
yourself, one of the definitions is certainly a synonym for uninamity

• and
  that's how I personally found it commonly used throughout my life.
  Regardless, it certainly implies no strong disagreement from those in
  the
  minority - which is not the case here.

A good reading on consensus in technical discussions is this:
https://tools.ietf.org/html/rfc7282

In my view there is a difference between a vote and consensus.

In a vote I state "this is my preference" in a consensus I can say "it
is not my preference, but I can support it" And I believe the key is to
identify whether there are objections/vetos. Those have to be
respected, as voting over volunteer contributors drives them away.
Voting is good if there is no clear consensus or if one has to make a
decision, left or right, and there's no clear consensus. Unanimity in a
vote means that this is the preferred approach for everybody (among
voters)

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.

johannes

On Tue, 23 Jul 2019 at 12:12, Johannes Schlüter johannes@schlueters.de
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,

Rowan Collins
[IMSoP]