Hi Internals,
I put forward the following RFC "Deprecate Backtick Operator (V2)" for
discussion.https://wiki.php.net/rfc/deprecate-backtick-operator-v2
I believe it is at least worth a discussion as to the pros and cons of
deprecating this functionality, especially in light of the existence of
better described and more well-known functions exhibiting identical
behaviour.This RFC only covers the issuing a deprecation notice, and its complete
removal would be contained within a separate RFC.
Usage of backtick operator in packagist top 2k packages:
https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594
There are 72 occurrences including duplicates.
Make of that whatever you will :)
Nikita
Hi Internals,
I put forward the following RFC "Deprecate Backtick Operator (V2)" for
discussion.https://wiki.php.net/rfc/deprecate-backtick-operator-v2
I believe it is at least worth a discussion as to the pros and cons of
deprecating this functionality, especially in light of the existence of
better described and more well-known functions exhibiting identical
behaviour.This RFC only covers the issuing a deprecation notice, and its complete
removal would be contained within a separate RFC.Usage of backtick operator in packagist top 2k packages:
https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594
There are 72 occurrences including duplicates.Make of that whatever you will :)
I did some further analysis on the output of Nikita's script.
Ignoring the duplicate WordPress package, all the occurrences
are in just 21 unique projects.
In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two occurrences.
Raw numbers: https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34
Best regards,
Theodore
Before replying (quickly) to this, I want to point out, again, that it’s
mind boggling we have to start discussing non-topics and spend time, energy
and mental strength on this endless stream of out-of-the-blue deprecation
proposals.
I did some further analysis on the output of Nikita's script.
Ignoring the duplicate WordPress package, all the occurrences
are in just 21 unique projects.
So in the non-representative sample of the PHP codebase at large, we have
it used in roughly 1% of the packages. That’s not “just” - that’s a lot
for a language as ridiculously popular as PHP is.
In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two
occurrences.
That’s another clue right there - of course it’s less likely to be found in
library code, and more likely to be found in admin scripts - which are in
turn less likely to be in packagist or otherwise public.
That said, the key point here has nothing to do with the popularity. It
has to do with the fact that nothing, absolutely nothing happened since
this feature was introduced to make us even consider removing it. Each and
every one of the supplied motivations for supposedly removing it existed in
exactly the same way when it was introduced.
Current internals@ folks having a different opinion over the exact same
facts is NOT sufficient grounds for removing it or even starting a
discussion about it. Something new and very substantial has to happen for
us to even start having this conversation. That’s how it’s always been and
that’s how it should stay.
Zeev
In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two occurrences.Raw numbers:https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34
The question that has to be asked here is how many legacy projects have
actually been moved to 'new' services like github, or even use code
management anyway. The vast majority of third party hosting is simply
based on isolated file management and even running clean-up tools are
not going to be easy. Especially where the original author who set up
the website is no longer around. While some hosts are maintaining the
old versions of PHP, more often these days the big players are buying up
small outfits and moving customers to new setups often without adequate
care. Which is why ANY unnecessary changes that need to be made as a
result are just painful often without ANY gain what so ever on either side?
--
Lester Caine - G8HFL
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
Which is why ANY unnecessary changes that need to be made as a
result are just painful often without ANY gain what so ever on either
side?
One gain that's very often overlooked on this list, is teaching a better
PHP to new generations. It IS confusing if PHP has more than one way to do
one thing, and if one of them is considered better than the other nowadays,
the other should be deprecated so that NEW code doesn't use it. Unless I
missed something, nobody in this thread has mentioned REMOVING backticks,
just DEPRECATING them. You don't HAVE to follow the deprecation with a
removal, at least not in a near future. But by deprecating the feature, at
least you're stopping the bleeding and (mostly) avoiding new code being
written that uses the legacy feature. Otherwise we'll have this discussion
again in 20 years, with the same outcome.
— Benjamin
In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two
occurrences.Raw numbers:
https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34The question that has to be asked here is how many legacy projects have
actually been moved to 'new' services like github, or even use code
management anyway. The vast majority of third party hosting is simply
based on isolated file management and even running clean-up tools are
not going to be easy. Especially where the original author who set up
the website is no longer around. While some hosts are maintaining the
old versions of PHP, more often these days the big players are buying up
small outfits and moving customers to new setups often without adequate
care. Which is why ANY unnecessary changes that need to be made as a
result are just painful often without ANY gain what so ever on either side?--
Lester Caine - G8HFLContact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
-----Original Message-----
From: Benjamin Morel [mailto:benjamin.morel@gmail.com]One gain that's very often overlooked on this list, is teaching a better PHP to
new generations. It IS confusing if PHP has more than one way to do one thing,
Not directly related to this RFC but out of curiosity - where does this "doing the same thing in multiple ways is confusing" comes from? (I mean this as serious question)
I had the impression that programming in essence is all about that - achieving/accomplishing something/the same different ways?
Because then you have to question a lot of things (not saying it's a bad thing) - like for example why does heredoc <<< (or nowdoc) exist when we have =, .= (also probably won't be found in most if any popular/public projects, libraries) and so on..
(While extreme) then dropping PHP just because there are 10 other programming languages that do the same thing (or even better) also becomes an argument because it is kind of "confusing for new generations" to pick and choose which one is better (Which one is more easy? Which uses less system resources/is faster? Where do you get more salary as employee? Etc)?
p.s. sorry for offtopic
rr
Not directly related to this RFC but out of curiosity - where does
this "doing the same thing in multiple ways is confusing" comes from?
(I mean this as serious question)I had the impression that programming in essence is all about that -
achieving/accomplishing something/the same different ways?
Of course there will always be an infinite number of logical ways to
structure a program, but this is quite different from having two
different syntaxes in a language that do exactly the same thing. The
latter is confusing since it's no longer clear which syntax should be
used. The same situation existed with the curly brace array/string
access syntax, which was deprecated in PHP 7.4.
To share my own experience, when I first started needing to run shell
commands in PHP and came across the backtick operator, I struggled to
understand the difference between it and shell_exec, and which
should be used in different circumstances. E.g. does the backtick
operator automatically escape variables? Is it faster than
shell_exec? It also caused me to assume that shell_exec must be
preferred for some reason over exec and proc_open since there is
a dedicated syntax for it.
Ultimately it made the whole process of learning how to correctly run
commands from PHP a lot more confusing than it should have been.
I know I'm not the only one that has been confused by it. If you look
at the PHP manual page for Execution Operators 1, the top voted
comment (by far) is from someone who accidentally typed a backtick
into their code and had a very difficult time debugging why their
script didn't work as expected.
As I see it, this syntax is not only confusing, but also dangerous.
A programmer coming from JavaScript might think the backticks are
simply storing a string, when in fact it will be executed as a command.
Furthermore, the (undocumented) ability to include variables in the
command can encourage terse but insecure scripts which fail to
properly escape user-supplied arguments.
Theodore
Le 31 oct. 2019 à 15:59, Theodore Brown theodorejb@outlook.com a écrit :
Of course there will always be an infinite number of logical ways to
structure a program, but this is quite different from having two
different syntaxes in a language that do exactly the same thing. The
latter is confusing since it's no longer clear which syntax should be
used. The same situation existed with the curly brace array/string
access syntax, which was deprecated in PHP 7.4.
Yeah, curly brace string access syntax were deprecated in PHP 7.4, and it was IMO an error. Last day, I reviewed an old library (PHPMarkdown), whose algorithm (probably directly ported from the original markdown written in Perl) was not very readable. Replacing all $string{$index} instances with $string[$index] made it even less readable, because the conventional distinction between string indexes and array indexes used in that library (and in several others libraries) were lost.
Sorry for the rant. But the message is: Existence of precedent is not an argument, because it may be a bad precedent.
—Claude
Den 2019-10-31 kl. 16:48, skrev Claude Pache:
Le 31 oct. 2019 à 15:59, Theodore Brown theodorejb@outlook.com a écrit :
Of course there will always be an infinite number of logical ways to
structure a program, but this is quite different from having two
different syntaxes in a language that do exactly the same thing. The
latter is confusing since it's no longer clear which syntax should be
used. The same situation existed with the curly brace array/string
access syntax, which was deprecated in PHP 7.4.Yeah, curly brace string access syntax were deprecated in PHP 7.4, and it was IMO an error. Last day, I reviewed an old library (PHPMarkdown), whose algorithm (probably directly ported from the original markdown written in Perl) was not very readable. Replacing all $string{$index} instances with $string[$index] made it even less readable, because the conventional distinction between string indexes and array indexes used in that library (and in several others libraries) were lost.
Sorry for the rant. But the message is: Existence of precedent is not an argument, because it may be a bad precedent.
—Claude
Hi,
I think that RFC was an example where there was a clear cut case
for removing curly brace array access, but not equally clear on to
remove it for curly brace string access.
In my eyes that RFC would have benefited from having two votes,
but the baby went out with the bathwater so to speak.
r//Björn L
Hi!
PHP to new generations. It IS confusing if PHP has more than one way to do
one thing, and if one of them is considered better than the other nowadays,
No it's not. At least no more than anything else in life. There's always
alternatives to do something. And PHP has always been a language where
having a convenient way of doing something that already has an
inconvenient way to do the same has always been welcomed.
the other should be deprecated so that NEW code doesn't use it. Unless I
missed something, nobody in this thread has mentioned REMOVING backticks,
This is not true, the RFC itself states:
Although the deprecation notice itself will carry no backwards
compatibility changes, this RFC is written with the intent that the
backtick operator would eventually be removed in a later version.
Did you read that part and conclude nobody mentioned REMOVING? How did
that work?
just DEPRECATING them. You don't HAVE to follow the deprecation with a
You don't have to, but the intent of this RFC is specifically stated as
such. Also, there's no reason to deprecate it either, for the same
reasons. There's absolutely nothing wrong with it except "it could make
somebody to look in the manual, potentially, so burn it with fire!"
least you're stopping the bleeding and (mostly) avoiding new code being
There's no bleeding and nothing to avoid.
written that uses the legacy feature. Otherwise we'll have this discussion
again in 20 years, with the same outcome.
It would be nice if we didn't, but unfortunately I suspect we will. Sigh.
--
Stas Malyshev
smalyshev@gmail.com
My, my this is a heated topic.
I am commenting in part because I do not have a dog in this hunt. I am okay leaving it, I am okay if it is deprecated. There are other things for PHP that I care far more about than this RFC. So...
I am wondering if everyone participating in this discussion would be willing to ask themselves "Is there any middle ground where I can respond in a way that is win-win for everyone involved?" rather than retreating to each other's respective corners and fighting as if to the death?
If I did not know better I would think this group was filled with members of the US Congress because of the unwillingness to compromise and seek common ground.
For example, would those who oppose this RFC change to support it if this was changed from:
Although the deprecation notice itself will carry no backwards
compatibility changes, this RFC is written with the intent that the
backtick operator would eventually be removed in a later version
To this?:
The deprecation notice will carry no backwards compatibility changes.
In addition this RFC is explicitly not recommending removal of the
backtick operator in a later version. To remove it — if ever desired —
will require an additional RFC to be passed.
Maybe the above resolves the objections against this RFC? Or maybe the above makes it useless in the minds of those who want to get rid of backtick? But this specific FRC does not matter to me
The point however, is can we not work to some form of happy medium rather than everyone fighting a zero sum game?
-Mike
#jmtcw
@Mike Schinkel,
a middle ground about/with silliness? there is none, for people in their
right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and mostly;
I have no say about deprecating that;
but is that a priority? does it harm anyone? someone have died from
backtick infection, it must be according to some?
and so on. Don't see where there is a heated topic; solely a reminder about
reality and facts.
Regards.
My, my this is a heated topic.
I am commenting in part because I do not have a dog in this hunt. I am
okay leaving it, I am okay if it is deprecated. There are other things for
PHP that I care far more about than this RFC. So...I am wondering if everyone participating in this discussion would be
willing to ask themselves "Is there any middle ground where I can respond
in a way that is win-win for everyone involved?" rather than retreating to
each other's respective corners and fighting as if to the death?If I did not know better I would think this group was filled with members
of the US Congress because of the unwillingness to compromise and seek
common ground.For example, would those who oppose this RFC change to support it if this
was changed from:Although the deprecation notice itself will carry no backwards
compatibility changes, this RFC is written with the intent that the
backtick operator would eventually be removed in a later version
To this?:
The deprecation notice will carry no backwards compatibility changes.
In addition this RFC is explicitly not recommending removal of the
backtick operator in a later version. To remove it — if ever desired —
will require an additional RFC to be passed.Maybe the above resolves the objections against this RFC? Or maybe the
above makes it useless in the minds of those who want to get rid of
backtick? But this specific FRC does not matter to meThe point however, is can we not work to some form of happy medium rather
than everyone fighting a zero sum game?-Mike
#jmtcw
@Mike Schinkel,
a middle ground about/with silliness? there is none, for people in their
right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and mostly;
I have no say about deprecating that;
but is that a priority? does it harm anyone? someone have died from
backtick infection, it must be according to some?
and so on. Don't see where there is a heated topic; solely a reminder about
reality and facts.Regards.
My, my this is a heated topic.
I am commenting in part because I do not have a dog in this hunt. I am
okay leaving it, I am okay if it is deprecated. There are other things
for
PHP that I care far more about than this RFC. So...I am wondering if everyone participating in this discussion would be
willing to ask themselves "Is there any middle ground where I can respond
in a way that is win-win for everyone involved?" rather than retreating
to
each other's respective corners and fighting as if to the death?If I did not know better I would think this group was filled with members
of the US Congress because of the unwillingness to compromise and seek
common ground.For example, would those who oppose this RFC change to support it if this
was changed from:Although the deprecation notice itself will carry no backwards
compatibility changes, this RFC is written with the intent that the
backtick operator would eventually be removed in a later version
To this?:
The deprecation notice will carry no backwards compatibility changes.
In addition this RFC is explicitly not recommending removal of the
backtick operator in a later version. To remove it — if ever desired —
will require an additional RFC to be passed.Maybe the above resolves the objections against this RFC? Or maybe the
above makes it useless in the minds of those who want to get rid of
backtick? But this specific FRC does not matter to meThe point however, is can we not work to some form of happy medium rather
than everyone fighting a zero sum game?-Mike
#jmtcw
What would a happy medium be? backticks working 50% of the time?
This is like someone being pregnant, either you are or you are not there is
no half pregnant.
Either backticks work like they have in shells for decades or they don't
work.
What's the point of deprecating them without a plan to remove them? A
notice without future action is a bad idea, as it sets standard that some
deprecation messages will not be acted upon.
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
a middle ground about/with silliness? there is none, for people in their right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and mostly; I have no say about deprecating that;
but is that a priority? does it harm anyone? someone have died from backtick infection, it must be according to some?
and so on. Don't see where there is a heated topic; solely a reminder about reality and facts.
What would a happy medium be? backticks working 50% of the time?
This is like someone being pregnant, either you are or you are not there is
no half pregnant. Either backticks work like they have in shells for decades
or they don't work. What's the point of deprecating them without a plan to
remove them? A notice without future action is a bad idea, as it sets
standard that some deprecation messages will not be acted upon.
Well, those are exactly the opposite of the types of responses I had hoped for.
Responses that ignore the concerns of others. Responses that (implicitly?) insult the intelligence of others. And responses that can only see things from one myopic perspective.
These responses highlight perfectly why discussions on this list are so contentious.
-Mike
Hello,
I answered you privately about this kind of false assumptions and
projections. (I have an education)
a middle ground about/with silliness? there is none, for people in their
right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and
mostly; I have no say about deprecating that;
but is that a priority? does it harm anyone? someone have died from
backtick infection, it must be according to some?
and so on. Don't see where there is a heated topic; solely a reminder
about reality and facts.What would a happy medium be? backticks working 50% of the time?
This is like someone being pregnant, either you are or you are not there
is
no half pregnant. Either backticks work like they have in shells for
decades
or they don't work. What's the point of deprecating them without a plan
to
remove them? A notice without future action is a bad idea, as it sets
standard that some deprecation messages will not be acted upon.Well, those are exactly the opposite of the types of responses I had hoped
for.Responses that ignore the concerns of others. Responses that (implicitly?)
insult the intelligence of others. And responses that can only see things
from one myopic perspective.These responses highlight perfectly why discussions on this list are so
contentious.-Mike
a middle ground about/with silliness? there is none, for people in their
right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and
mostly; I have no say about deprecating that;
but is that a priority? does it harm anyone? someone have died from
backtick infection, it must be according to some?
and so on. Don't see where there is a heated topic; solely a reminder
about reality and facts.What would a happy medium be? backticks working 50% of the time?
This is like someone being pregnant, either you are or you are not there
is
no half pregnant. Either backticks work like they have in shells for
decades
or they don't work. What's the point of deprecating them without a plan
to
remove them? A notice without future action is a bad idea, as it sets
standard that some deprecation messages will not be acted upon.Well, those are exactly the opposite of the types of responses I had hoped
for.
Mike,
In a parallel universe, where this proposal has never been created and
brought up for discussion - backticks would continue to work precisely as
they did for twenty years, precisely with the advantages and disadvantages
they had the day they were introduced, and this continue being the
non-issue that it’s always been. Nobody would be thinking about it,
opining about it and let alone quarreling about it.
Unfortunately, we don’t live in that parallel universe, and suddenly this
thing that bugged nobody for decades becomes a sudden priority for
discussion. It’s also not as if we can ignore it either - we’ve seen how
that went with short tags. So while I sympathize with the effort to find a
compromise - encouraging more of these contentious proposals (by
accommodating them at some level) is not the way.
The real middle ground is to go for some form of opt-in solution. Whether
it’s granular declares, strict mode, P++, editions - this is the only way
to diffuse this contention - by rendering it irrelevant - precisely as it
should be. Contrary to the perception many here appear to be under,
there’s no feasibility question-mark over any of these options - they’re
all doable, and even easy to implement. This solution would also not be
some band aid until the next out of the blue proposal comes along - but a
framework to thoroughly diffuse these types of contention once and for all.
Zeev
So while I sympathize with the effort to find a compromise - encouraging more of these contentious proposals (by accommodating them at some level) is not the way.
Ok, but...
The real middle ground is to go for some form of opt-in solution. Whether it’s granular declares, strict mode, P++, editions - this is the only way to diffuse this contention - by rendering it irrelevant - precisely as it should be. Contrary to the perception many here appear to be under, there’s no feasibility question-mark over any of these options - they’re all doable, and even easy to implement. This solution would also not be some band aid until the next out of the blue proposal comes along - but a framework to thoroughly diffuse these types of contention once and for all.
...it seems you have identified at least one way to seek compromise. Why not move forward with this, in general?
Said another way, why not discuss and debate BC breakage in abstract — and any other contention topics — and then establish a set of principles that the community can agree to use?
This could be done in an RFC, and much like Mission, Vision and Values statements that organizations use to help them decide if they should pursue specific opportunities, a set of principles like these could help the internals@ have the debates once, in abstract, and then apply those principles to evaluate future RFCs? If course really cut down on ongoing contentious debate.
I would create an RFC like that but AFAIK I have not developed enough clout here thus far so it would have to be from someone already well respected.
-Mike
P.S. You argument against compromises ironically soundsvery similar to the argument that leaving certain syntax in PHP encourages people to use it, and thus write "bad" code. Do you not see the similarities?
...it seems you have identified at least one way to seek compromise. Why
not move forward with this, in general?
I did - quite a while ago - and I see no reason not to, except that the
pro-strict/pro-let’s-break-things camp either ignores that proposal
entirely, or calls it a fork (it’s a fork in precisely the same way that
PHP is a spoon).
Note that I don’t really view it as a compromise, which is why I wrote my
reply to you the way that I did. Instead, I see it as a complete win/win
for both camps. It’s radically different from thoroughly entertaining each
and every proposal with the inevitable contentious discussion that would
ensue - in the context of changing PHP and both forcing people to change
how they work as well as break existing code - and come up with some
technical middle ground between “we shouldn’t touch it” and “we must kill
it”.
Said another way, why not discuss and debate BC breakage in abstract — and
any other contention topics — and then establish a set of principles that
the community can agree to use?
I don’t know. The last time I tried to do it, someone pulled an overnight
pseudo-RFC to stop the discussion, radically mischaracterizing the
proposal, abusing a vote to shutdown discussion, and creating the
fundamentally wrong impression that this is about the technical feasibility
of achieving this - and not about whether we want to go down that route or
not. I’m all for discussing it (the principle, not necessarily in the P++
form).
I would create an RFC like that but AFAIK I have not developed enough clout
here thus far so it would have to be from someone already well respected.
As I wrote a couple of weeks back, before we agree on the principle - that
these contentious, breaking-for-no-new-reason proposals can’t be forced on
everyone but we need to make it opt-in, I don’t think formalizing it into
an RFC would help. I could be wrong, but I think we’re currently lacking
in good will on the other camp, which appears to feel a lot more
comfortable to just go on producing contentious proposals day in and day
out, and live with whatever sticks.
P.S. You argument against compromises ironically soundsvery similar to the
argument that leaving certain syntax in PHP encourages people to use it,
and thus write "bad" code. Do you not see the similarities?
In a nutshell, no, not really. Feel free to try to convince me otherwise
off list - I’ll report back if convinced :)
Zeev
As I wrote a couple of weeks back, before we agree on the principle - that
these contentious, breaking-for-no-new-reason proposals can’t be forced on
everyone but we need to make it opt-in, I don’t think formalizing it into
an RFC would help. I could be wrong, but I think we’re currently lacking
in good will on the other camp, which appears to feel a lot more
comfortable to just go on producing contentious proposals day in and day
out, and live with whatever sticks.
Tangent: I think it's a mischaracterization to divide opinions about PHP's future into "two camps", one of which wants to defend BC and never change anything and make the language as loosy-goosey as possible, and one that doesn't care about BC and wants to turn it into Haskell. Those are hyperbolic and incorrect descriptions of where I see people standing, and creating that "two warring camps" impression only makes the question about how PHP should evolve harder to resolve.
There are several distinct axes of philosophical debate, and they do not necessarily correlate at all.
- More BC protection vs less.
- More opt-in "syntactic error checking" (eg, typing) vs less.
- Fail hard on error cases vs "assume what was probably intended".
- More "simplify common tasks" sugar vs less.
- "performance reigns supreme" vs "spending performance to get usability is a good tradeoff".
And probably many others I can't think of right now. Those various axes do not all correlate, and I suspect all 32 combinations of answers to those questions are represented by someone on this list, even before getting to the fact that they're all scales, not binaries, and some overlap in interesting ways (eg, failing hard is in some cases a BC break, others not).
Zeev, you're very strongly and vocally on the "more BC protection" side. That's fine; I agree with you, by and large. But lumping "pfft, BC" in with "moar types" and "fail hard" and "moar sugar" and then dismissing them as "the other camp" does not advance the cause of BC protection, nor does it advance the cause of Internals not being a running gag of dysfunction, nor does it advance the cause of making PHP a better language, for any definition of better.
As long as "anyone is allowed to propose an RFC", we will get RFCs that go against the informal consensus. Over time, that informal consensus will thus shift. That is an inevitable and unavoidable result of PHP's loosey-goosey structure.
If you want to really protect BC, the way to do that is to actually put guidelines in writing that people have to read before proposing an RFC, and that we can point to when people ignore them anyway. But "that's how we've always done it, no it's not written down but we really have" is an approach doomed to not only fail, but to maximize the amount of strife as it fails. Let's please not do that.
And developing such guidelines absolutely positively cannot happen on a public asynchronous mailing list. I've been through such processes enough times to know that is the worst possible way to do it.
--Larry Garfield
And developing such guidelines absolutely positively cannot happen on a public asynchronous mailing list. I've been through such processes enough times to know that is the worst possible way to do it.
When I first saw this email I thought you were proposing IRL "camp" ala a symposium/convention/assembly where "delegates" from the internals@ list were to get together face-to-face and collaborate on moving PHP forward. I think people might be a lot more willing to work together for mutual benefit if they were working in the same room rather than on their own in front of their keyboards.
Maybe that would be a way to move forward with some of the log jams here? Basically an initial meeting and then a plan to do it periodically in the future (annual or bi-annual?)
-Mike
Hi!
Maybe that would be a way to move forward with some of the log jams here?
I'm not sure where's the log jam here? An RFC proposing largely
pointless deprecation not being met with overall enthusiasm is not a
"logjam". It's a logjam only if somehow we were to imagine more BC
breaks, more deprecations and more removal of functionality is somehow
vitally necessary for PHP - which decades of thriving without all that
amply prove to be false.
I don't see what's wrong with just "do not break BC unless you
absolutely can't avoid it" and why we need some grand World Council to
arrive to this simple guideline that has been understood as obvious for
years and has been also accepted by many other software projects? How
comes now we have to spend so much time at affirming the obvious?
Stas Malyshev
smalyshev@gmail.com
I'm not sure where's the log jam here?
The issue is not this specific RFC.
As I wrote earlier, there appear to be heated and non-stop debates over (at least) BC, and possibly other areas. People dig in on a position and then won't consider any other options that might be available.
It's a logjam only if somehow we were to imagine more BC
breaks, more deprecations and more removal of functionality is somehow
vitally necessary for PHP - which decades of thriving without all that
amply prove to be false.
Let me restate then, because what was important was not that the word I used matched internals@ circumstances exactly, but the fact that there is an issue with how the process currently works, as many other people have noted already.
We can call it something other than a logjam if it is important to you that the word matches. What about dysfunction instead?
I don't see what's wrong with just "do not break BC unless you
absolutely can't avoid it"... How comes now we have to spend
so much time at affirming the obvious?
Frankly I would agree with that, if it were not for a large number of people who are actively promoting changes to PHP that would break BC. So clearly the current composition of this list includes people who see something wrong with the approach you see no reason to question.
Note I am not endorsing their opinion but I am recognizing they have this opinion and they are actively trying to change PHP. So we can embrace insanity — as Einstein would say — and fight never-ending battles on the list, or we can find ways to accommodate everyones needs and wants, assuming everyone else is willing to find way to accommodate the needs and wants of people that disagree with them.
Looking in from the outside, few people who send emails to this list appear to be interested in finding common ground. But maybe if we help everyone recognize that nobody wins — including themselves — when a group of people divide up and stake out intransigent and diametrically-opposed positions then the list can be a lot more productive.
No single person owns PHP so it is rather ungenerous to adopt a view that PHP should conform to any one individual view of the perfect programming language. So what if instead we collectively ask ourselves the question "What can I do to meet the other people half way — in ways that won't really cost me all that much — rather than to maintain an unrelentingly rigid posture about the needs and wants of others?"
-Mike
I'm not sure where's the log jam here?
The issue is not this specific RFC.
As I wrote earlier, there appear to be heated and non-stop debates over
(at least) BC, and possibly other areas. People dig in on a position and
then won't consider any other options that might be available.It's a logjam only if somehow we were to imagine more BC
breaks, more deprecations and more removal of functionality is somehow
vitally necessary for PHP - which decades of thriving without all that
amply prove to be false.Let me restate then, because what was important was not that the word I
used matched internals@ circumstances exactly, but the fact that there is
an issue with how the process currently works, as many other people have
noted already.We can call it something other than a logjam if it is important to you
that the word matches. What about dysfunction instead?I don't see what's wrong with just "do not break BC unless you
absolutely can't avoid it"... How comes now we have to spend
so much time at affirming the obvious?Frankly I would agree with that, if it were not for a large number of
people who are actively promoting changes to PHP that would break BC. So
clearly the current composition of this list includes people who see
something wrong with the approach you see no reason to question.Note I am not endorsing their opinion but I am recognizing they have this
opinion and they are actively trying to change PHP. So we can embrace
insanity — as Einstein would say — and fight never-ending battles on the
list, or we can find ways to accommodate everyones needs and wants,
assuming everyone else is willing to find way to accommodate the needs and
wants of people that disagree with them.Looking in from the outside, few people who send emails to this list
appear to be interested in finding common ground. But maybe if we help
everyone recognize that nobody wins — including themselves — when a group
of people divide up and stake out intransigent and diametrically-opposed
positions then the list can be a lot more productive.No single person owns PHP so it is rather ungenerous to adopt a view that
PHP should conform to any one individual view of the perfect programming
language. So what if instead we collectively ask ourselves the question
"What can I do to meet the other people half way — in ways that won't
really cost me all that much — rather than to maintain an unrelentingly
rigid posture about the needs and wants of others?"-Mike
Mike - I have no issue with compromise when it makes sense. Sometimes,
though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One
side wants to build a 100 yard bridge to an island. The other side doesn't
think we need to build the bridge because we don't need to go to the
island. What's the compromise? Building a 50 yard bridge?
The fact is, when there is a compromise that makes sense, people usually
suggest it. One example being Zeev's proposal on the RFC to raise the error
levels of undefined variables to making it opt-in. Zeev's stance on the
issue was that we shouldn't do anything that was mentioned in the RFC, but,
he felt that a compromise would be to at least make those changes opt-in.
That proposal was rejected by pretty much everyone. That's probably why it
wasn't proposed this time, either.
As for this particular RFC, I think it's a pretty binary decision.
Deprecate them or don't. As long as I've been involved with PHP, nothing is
ever deprecated unless the eventual goal is to remove it. I could be wrong,
and welcome examples where we've deprecated something where the end goal
wasn't removal. Assuming I'm correct though, that provides a pretty strong
reason for why we wouldn't start doing it now.
--
Chase Peeler
chasepeeler@gmail.com
On Thu, Oct 10, 2019 at 12:11 AM Mike Schinkel mike@newclarity.net
wrote:I'm not sure where's the log jam here?
The issue is not this specific RFC.
As I wrote earlier, there appear to be heated and non-stop debates over
(at least) BC, and possibly other areas. People dig in on a position and
then won't consider any other options that might be available.It's a logjam only if somehow we were to imagine more BC
breaks, more deprecations and more removal of functionality is somehow
vitally necessary for PHP - which decades of thriving without all that
amply prove to be false.Let me restate then, because what was important was not that the word I
used matched internals@ circumstances exactly, but the fact that there
is
an issue with how the process currently works, as many other people have
noted already.We can call it something other than a logjam if it is important to you
that the word matches. What about dysfunction instead?I don't see what's wrong with just "do not break BC unless you
absolutely can't avoid it"... How comes now we have to spend
so much time at affirming the obvious?Frankly I would agree with that, if it were not for a large number of
people who are actively promoting changes to PHP that would break BC. So
clearly the current composition of this list includes people who see
something wrong with the approach you see no reason to question.Note I am not endorsing their opinion but I am recognizing they have this
opinion and they are actively trying to change PHP. So we can embrace
insanity — as Einstein would say — and fight never-ending battles on the
list, or we can find ways to accommodate everyones needs and wants,
assuming everyone else is willing to find way to accommodate the needs
and
wants of people that disagree with them.Looking in from the outside, few people who send emails to this list
appear to be interested in finding common ground. But maybe if we help
everyone recognize that nobody wins — including themselves — when a group
of people divide up and stake out intransigent and diametrically-opposed
positions then the list can be a lot more productive.No single person owns PHP so it is rather ungenerous to adopt a view that
PHP should conform to any one individual view of the perfect programming
language. So what if instead we collectively ask ourselves the question
"What can I do to meet the other people half way — in ways that won't
really cost me all that much — rather than to maintain an unrelentingly
rigid posture about the needs and wants of others?"-Mike
Mike - I have no issue with compromise when it makes sense. Sometimes,
though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One
side wants to build a 100 yard bridge to an island. The other side doesn't
think we need to build the bridge because we don't need to go to the
island. What's the compromise? Building a 50 yard bridge?
No. The compromise is funding a ferry system. Or laying Internet between
them. Or a passenger pigeon mail route.
Sometimes compromise requires deep discussion about the motivations for
each side and coming to a lateral, mutually acceptable, solution.
But we'd rather not discuss motivations and just bicker about the surface
results. I.e., argue the X, rather than the Y, of these little XY problems
we're solving.
The fact is, when there is a compromise that makes sense, people usually
suggest it. One example being Zeev's proposal on the RFC to raise the error
levels of undefined variables to making it opt-in. Zeev's stance on the
issue was that we shouldn't do anything that was mentioned in the RFC, but,
he felt that a compromise would be to at least make those changes opt-in.
That proposal was rejected by pretty much everyone. That's probably why it
wasn't proposed this time, either.As for this particular RFC, I think it's a pretty binary decision.
Deprecate them or don't. As long as I've been involved with PHP, nothing is
ever deprecated unless the eventual goal is to remove it. I could be wrong,
and welcome examples where we've deprecated something where the end goal
wasn't removal. Assuming I'm correct though, that provides a pretty strong
reason for why we wouldn't start doing it now.
Short tags are deprecated, per the manual. They are not planned to be
removed and, per the vote discussions and margins, probably won't ever go.
No. The compromise is funding a ferry system. Or laying Internet between
them. Or a passenger pigeon mail route.Sometimes compromise requires deep discussion about the motivations for
each side and coming to a lateral, mutually acceptable, solution.But we'd rather not discuss motivations and just bicker about the surface
results. I.e., argue the X, rather than the Y, of these little XY problems
we're solving.
Build a ferry system is alternative to building bridge. I can see that as a
compromise, I can also see that as a separate project created to serve
demand after the the bridge project is rejected. Where a ferry system is
started because there is still demand for transit, just not enough demand
to pay for a bridge.
With respect to the backtick proposal, what is the "ferry" project? Do we
have to come up with one before we can cancel the "bridge" project or can
we cancel the "bridge" project on its own merits and then discuss a future
project that solves the actual underlying problem?
"Ferry" projects might be: more/better training on PHP, better
documentation so that the backtick is no longer an "obscure" feature to
those that don't have a shell/Unix/Perl background, tooling to warn people
when they misuse this feature.
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
No. The compromise is funding a ferry system. Or laying Internet between
them. Or a passenger pigeon mail route.Sometimes compromise requires deep discussion about the motivations for
each side and coming to a lateral, mutually acceptable, solution.But we'd rather not discuss motivations and just bicker about the surface
results. I.e., argue the X, rather than the Y, of these little XY
problems
we're solving.Build a ferry system is alternative to building bridge. I can see that as a
compromise, I can also see that as a separate project created to serve
demand after the the bridge project is rejected. Where a ferry system is
started because there is still demand for transit, just not enough demand
to pay for a bridge.With respect to the backtick proposal, what is the "ferry" project? Do we
have to come up with one before we can cancel the "bridge" project or can
we cancel the "bridge" project on its own merits and then discuss a future
project that solves the actual underlying problem?"Ferry" projects might be: more/better training on PHP, better
documentation so that the backtick is no longer an "obscure" feature to
those that don't have a shell/Unix/Perl background, tooling to warn people
when they misuse this feature.
To the side that says "There is absolutely no reason we need to go to, or
communicate with, the island in the first place," a ferry project isn't a
compromise. The position of the "anti-bridge" builders isn't because they
are against building bridges - it's because they are against spending
resources on attempts to get to the island in the first place. The other
side might have valid arguments on why we need to get to the island, but,
just proposing different ways to get there isn't compromising with the side
that doesn't want to go there.
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D.
Brandeis
--
Chase Peeler
chasepeeler@gmail.com
No. The compromise is funding a ferry system. Or laying Internet between
them. Or a passenger pigeon mail route.Sometimes compromise requires deep discussion about the motivations for
each side and coming to a lateral, mutually acceptable, solution.But we'd rather not discuss motivations and just bicker about the
surface
results. I.e., argue the X, rather than the Y, of these little XY
problems
we're solving.Build a ferry system is alternative to building bridge. I can see that as
a
compromise, I can also see that as a separate project created to serve
demand after the the bridge project is rejected. Where a ferry system is
started because there is still demand for transit, just not enough demand
to pay for a bridge.With respect to the backtick proposal, what is the "ferry" project? Do we
have to come up with one before we can cancel the "bridge" project or can
we cancel the "bridge" project on its own merits and then discuss a future
project that solves the actual underlying problem?"Ferry" projects might be: more/better training on PHP, better
documentation so that the backtick is no longer an "obscure" feature to
those that don't have a shell/Unix/Perl background, tooling to warn people
when they misuse this feature.To the side that says "There is absolutely no reason we need to go to, or
communicate with, the island in the first place," a ferry project isn't a
compromise. The position of the "anti-bridge" builders isn't because they
are against building bridges - it's because they are against spending
resources on attempts to get to the island in the first place. The other
side might have valid arguments on why we need to get to the island, but,
just proposing different ways to get there isn't compromising with the side
that doesn't want to go there.
I think you may have just created a strawman for the anti-bridge position.
There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska
(if you don't remember, there was an island in Alaska that had 50 people
and Senator Stevens wanted to replace the existing ferry system with a $398
million bridge). People complained about the bridge not because they wanted
the islanders to to isolated, but because it was poor use of money when
there where bigger and more urgent problems.
To bring this back to PHP, is the backtick really a urgent problem of
enough magnitude that it justifies the cost of a BC break in unknown amount
of PHP code that has been functional for years. If this proposal passes
(and the follow up to remove it which I'm certain will be proposed), then
this is one that leaves people on the island as they will either be stuck
on an old version of PHP or have to pay to update the code. This pushes the
costs on them to solve a an existing issue that 20 years after it was
created and is now an issue because a new generation of coders, unaware of
history, find the existing syntax not to there taste/a poor design. Why are
we giving priority to people that haven't taken the time to educate
themselves over people that did and used programming style that used to
common?
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D.
Brandeis--
Chase Peeler
chasepeeler@gmail.com
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
They will either be stuck on an old version of PHP or have to pay to update the code.
If you're getting stuck on a island after being given 4 or 5 years
warning that the bridge to it will be closed, after being pointed to the
ferry, given free tickets to that ferry, and being told it will continue
to run long after, that's your own fault.
This pushes the
costs on them to solve a an existing issue that 20 years after it was
created and is now an issue because a new generation of coders, unaware of
history, find the existing syntax not to there taste/a poor design.
History does not mean it was a good idea at the time, and even if it
was, that doesn't mean it's a good idea now. Times move on. Your
argument could easily be reversed...
An old generation of coders, stuck in their ways, inflexible, preferring
what they know rather than changing with the times for the greater good.
Why are
we giving priority to people that haven't taken the time to educate
themselves over people that did and used programming style that used to
common?
We're assuming that in a general purpose programming languages, most
programmers expect a function call to look like a function call, and not
a string.
We're assuming that people don't just go from never having touched PHP,
to expert level, knowing all its quirks and secrets, within a few hours.
We're assuming that there's a heck of a lot more to stewardship of the
language than backwards compatibility.
So let's look at it from the perspective of what we can do...
We can either a) Find a way to reach out to every PHP programmer in the
world and let them know that there's these special operators that look
like a string, but actually aren't, and they do something that can be
really dangerous, and they'll probably never see it but god help them if
it's there and they miss it.
or
b) We add one line of code and warn people that we're eventually going
to remove a rarely used and poorly understood syntax, and people should
at some point in the next 4 or 5 migrate to the much more obvious
shell_exec.
By writing the RFC, it's pretty obvious which one I think is the best
and most realistic course of action.
Mark Randall
No. The compromise is funding a ferry system. Or laying Internet between
them. Or a passenger pigeon mail route.Sometimes compromise requires deep discussion about the motivations for
each side and coming to a lateral, mutually acceptable, solution.But we'd rather not discuss motivations and just bicker about the
surface
results. I.e., argue the X, rather than the Y, of these little XY
problems
we're solving.Build a ferry system is alternative to building bridge. I can see that as
a
compromise, I can also see that as a separate project created to serve
demand after the the bridge project is rejected. Where a ferry system is
started because there is still demand for transit, just not enough demand
to pay for a bridge.With respect to the backtick proposal, what is the "ferry" project? Do we
have to come up with one before we can cancel the "bridge" project or can
we cancel the "bridge" project on its own merits and then discuss a future
project that solves the actual underlying problem?"Ferry" projects might be: more/better training on PHP, better
documentation so that the backtick is no longer an "obscure" feature to
those that don't have a shell/Unix/Perl background, tooling to warn people
when they misuse this feature.To the side that says "There is absolutely no reason we need to go to, or
communicate with, the island in the first place," a ferry project isn't a
compromise. The position of the "anti-bridge" builders isn't because they
are against building bridges - it's because they are against spending
resources on attempts to get to the island in the first place. The other
side might have valid arguments on why we need to get to the island, but,
just proposing different ways to get there isn't compromising with the side
that doesn't want to go there.I think you may have just created a strawman for the anti-bridge position.
There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska
(if you don't remember, there was an island in Alaska that had 50 people
and Senator Stevens wanted to replace the existing ferry system with a $398
million bridge). People complained about the bridge not because they wanted
the islanders to to isolated, but because it was poor use of money when
there where bigger and more urgent problems.To bring this back to PHP, is the backtick really a urgent problem of
enough magnitude that it justifies the cost of a BC break in unknown amount
of PHP code that has been functional for years. If this proposal passes
(and the follow up to remove it which I'm certain will be proposed), then
this is one that leaves people on the island as they will either be stuck
on an old version of PHP or have to pay to update the code. This pushes the
costs on them to solve a an existing issue that 20 years after it was
created and is now an issue because a new generation of coders, unaware of
history, find the existing syntax not to there taste/a poor design. Why are
we giving priority to people that haven't taken the time to educate
themselves over people that did and used programming style that used to
common?Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D.
Brandeis--
Chase Peeler
chasepeeler@gmail.com--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
(Sorry, wrong account previously, so didn’t sent to the list)
Hi Walter,
The RFC at the centre of this ridiculous string of analogies is about one thing: deprecate (i.e. show a deprecation message) about the backtick operator.
The RFC specifically doesn’t lay out a timeline for actual removal, it doesn’t even hint at “well it’ll just be automatically removed”.
So this RFC breaks nothing.
Yes, it does lead to the situation where it’s likely that a followup RFC will propose removing the (then) deprecated feature - perhaps 9.0, perhaps it’ll be discussed pre-9.0, and held off until 10.0? But any such change will then require another vote, with another round of discussions and no doubt ridiculous analogies.
And at that time, after several years of warnings about deprecation, Nikita or someone else will likely pop up with some analysis of projects to show usage at the time.
If the only reason to keep a dangerous operator is “well a small subset of people use it”, marking it as deprecated is how you signal to those people that the feature will likely be removed in a future version.
The argument about “shell style scripts” that are on a server which constantly gets updated to the newest release but never gets any maintenance to the scripts is a ridiculous fantasy.
There is zero chance someone is dist-upgrading from one release to the next through enough versions that they get to one where the distro-provided php is such that backticks are actually removed, and yet the only thing that breaks is the backticks.
Cheers
Stephen
"Ferry" projects might be: more/better training on PHP, better
documentation so that the backtick is no longer an "obscure" feature to
those that don't have a shell/Unix/Perl background, tooling to warn people
when they misuse this feature.
Unfortunately most of those are out of our hands.
While it would certainly be great if we could better educate everyone,
such things are beyond the power of internals to do, and while we could
improve the documentation, we're not in a position to tell everyone that
new information is there, and even still, that wouldn't change that it's
too easy to miss for the power it possesses.
While a warning would be something, PHP's warnings don't actually
prevent anything. By the time you see them, the problem has usually
already occurred.
That leaves us with the choice that's within our power, deprecation and
eventual removal of backticks in favour of something that's much more
obvious in its intent and much less easy to miss.
Mark Randall
My, my this is a heated topic.
I am commenting in part because I do not have a dog in this hunt. I am
okay leaving it, I am okay if it is deprecated. There are other things for
PHP that I care far more about than this RFC. So...I am wondering if everyone participating in this discussion would be
willing to ask themselves "Is there any middle ground where I can respond
in a way that is win-win for everyone involved?" rather than retreating to
each other's respective corners and fighting as if to the death?
Hi,
My middle ground is a vote, regardless of outcome. This RFC is pretty
simple, a deprecation + removal in a later patch, there's not much to
compromise on the implementation. If people think a deprecation should not
be done or if it's not worth it, a vote is the way to show that opinion.
Pros and cons have been given and people have different opinions about
those. Currently a few people on the mailing list are very vocal up to a
point where it becomes obnoxious to read their replies, and others are
stating that this RFC shouldn't even go into a vote. If there are enough
reasons to not deprecate them, the voting process will show this and the
RFC will be rejected.
Regards,
Lynn van der Berg
PS. We need a CoC.
My middle ground is a vote, regardless of outcome.
If a vote is the middle ground then why the need to participate in any discussion?
Also, how is a vote a middle ground? A vote ensures that one sides wins and the other side looses. IOW, a zero-sum game.
Why does it not make better sense to actively look for ways to optimize outcomes so that the most people can win? For example...
This RFC is pretty simple, a deprecation + removal in a later patch, there's not much to compromise on the implementation.
A compromise might be "NO agreement to remove in a later patch."
Why does it not make sense to offer that up as a consolation to the one asking for deprecation? If they accepted and changed the RFC, then more people could get a "win."
If people think a deprecation should not be done or if it's not worth it, a vote is the way to show that opinion.
If there are enough reasons to not deprecate them, the voting process will show this and the RFC will be rejected.
I have noticed on this list much discussion of the "minority vs. the majority." But that is a red-herring. There are a small number of people who have a vote (~200?) whereas there are over 5 million PHP developers and even more PHP stakeholders who have no vote.
In other words, when internals@ votes unanimously on an RFC they still only represent ~0.004% of PHP stakeholders. Basically an aristocracy.
So while a vote is a way to share an opinion, it is not representative of the opinions of those it may affect. It is a shame that the PHP voting process has no objective way to incorporate userland concerns except when some act as their proxy. Which is not the same as userland having explicit representatives with a vote.
PS. We need a CoC.
100% agree.
-Mike
P.S. I also think PHP needs an agreed statement of principles (Mission, Vision and Values.) With said statement RFCs could be evaluated to determine if they align with PHP's previously-agreed principles. Such a statement could be revised from time to time, but having one would resolve a lot of contentious debates before they happen.
Hello,
what you write and advocate for can't be heard by a vast majority of people
here; because they are just not North-American; somehow
that's a very interesting trait; most of people despise kind moralism.
My middle ground is a vote, regardless of outcome.
If a vote is the middle ground then why the need to participate in any
discussion?Also, how is a vote a middle ground? A vote ensures that one sides wins
and the other side looses. IOW, a zero-sum game.Why does it not make better sense to actively look for ways to optimize
outcomes so that the most people can win? For example...This RFC is pretty simple, a deprecation + removal in a later patch,
there's not much to compromise on the implementation.A compromise might be "NO agreement to remove in a later patch."
Why does it not make sense to offer that up as a consolation to the one
asking for deprecation? If they accepted and changed the RFC, then more
people could get a "win."If people think a deprecation should not be done or if it's not worth
it, a vote is the way to show that opinion.
If there are enough reasons to not deprecate them, the voting process
will show this and the RFC will be rejected.I have noticed on this list much discussion of the "minority vs. the
majority." But that is a red-herring. There are a small number of people
who have a vote (~200?) whereas there are over 5 million PHP developers and
even more PHP stakeholders who have no vote.In other words, when internals@ votes unanimously on an RFC they still
only represent ~0.004% of PHP stakeholders. Basically an aristocracy.So while a vote is a way to share an opinion, it is not representative of
the opinions of those it may affect. It is a shame that the PHP voting
process has no objective way to incorporate userland concerns except when
some act as their proxy. Which is not the same as userland having explicit
representatives with a vote.PS. We need a CoC.
100% agree.
-Mike
P.S. I also think PHP needs an agreed statement of principles (Mission,
Vision and Values.) With said statement RFCs could be evaluated to
determine if they align with PHP's previously-agreed principles. Such a
statement could be revised from time to time, but having one would resolve
a lot of contentious debates before they happen.
Hello,
what you write and advocate for can't be heard by a vast majority of people
here; because they are just not North-American; somehow
that's a very interesting trait; most of people despisekindmoralism.My middle ground is a vote, regardless of outcome.
If a vote is the middle ground then why the need to participate in any
discussion?Also, how is a vote a middle ground? A vote ensures that one sides wins
and the other side looses. IOW, a zero-sum game.Why does it not make better sense to actively look for ways to optimize
outcomes so that the most people can win? For example...This RFC is pretty simple, a deprecation + removal in a later patch,
there's not much to compromise on the implementation.A compromise might be "NO agreement to remove in a later patch."
Why does it not make sense to offer that up as a consolation to the one
asking for deprecation? If they accepted and changed the RFC, then more
people could get a "win."If people think a deprecation should not be done or if it's not worth
it, a vote is the way to show that opinion.
If there are enough reasons to not deprecate them, the voting process
will show this and the RFC will be rejected.I have noticed on this list much discussion of the "minority vs. the
majority." But that is a red-herring. There are a small number of people
who have a vote (~200?) whereas there are over 5 million PHP developers
and
even more PHP stakeholders who have no vote.In other words, when internals@ votes unanimously on an RFC they still
only represent ~0.004% of PHP stakeholders. Basically an aristocracy.So while a vote is a way to share an opinion, it is not representative of
the opinions of those it may affect. It is a shame that the PHP voting
process has no objective way to incorporate userland concerns except when
some act as their proxy. Which is not the same as userland having
explicit
representatives with a vote.PS. We need a CoC.
100% agree.
-Mike
P.S. I also think PHP needs an agreed statement of principles (Mission,
Vision and Values.) With said statement RFCs could be evaluated to
determine if they align with PHP's previously-agreed principles. Such a
statement could be revised from time to time, but having one would
resolve
a lot of contentious debates before they happen.
The original proposal reads like: I don't understand it, I've talked to
other that don't understand it. Not understand something makes learning the
language harder, so we should get rid of the feature.
How is this not Mark Twain's plan for the Improvement of Spelling in the
English language?
A Plan for the Improvement of Spelling in the English Language
By Mark Twain
For example, in Year 1 that useless letter “c” would be dropped to be
replased either by “k” or “s”, and likewise “x” would no longer be part of
the alphabet. The only kase in which “c” would be retained would be the
“ch” formation, which will be dealt with later. Year 2 might reform “w”
spelling, so that “which” and “one” would take the same konsonant, wile
Year 3 might well abolish “y” replasing it with “i” and iear 4 might fiks
the “g/j” anomali wonse and for all.
Generally, then, the improvement would kontinue iear bai iear with iear 5
doing awai with useless double konsonants, and iears 6-12 or so modifaiing
vowlz and the rimeiniing voist and unvoist konsonants. Bai iear 15 or sou,
it wud fainali bi posibl tu meik ius ov thi ridandant letez “c”, “y” and
“x”—bai now jast a memori in the maindz ov ould doderez —tu riplais “ch”,
“sh”, and “th” rispektivili.
Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl,
kohirnt speling in ius xrewawt xe Ingliy-spiking werld.
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Hi,
If a vote is the middle ground then why the need to participate in any
discussion?Also, how is a vote a middle ground? A vote ensures that one sides wins
and the other side looses. IOW, a zero-sum game.Why does it not make better sense to actively look for ways to optimize
outcomes so that the most people can win? For example...
There is no middle ground in an RFC that proposes the deprecation at this
level of specifics. You either deprecate it, or you don't. The only middle
ground you can reach, is that you give it a vote to see if it should indeed
be deprecated. Perhaps I'm looking at it from a wrong perspective, it looks
very binary to me (see next answer for why).
A compromise might be "NO agreement to remove in a later patch."
Why does it not make sense to offer that up as a consolation to the one
asking for deprecation? If they accepted and changed the RFC, then more
people could get a "win."
The idea behind a deprecation is that you are discouraging its use and plan
to remove it at a later stage. To me it makes no sense to deprecate
something but never remove it, might as well not deprecate it at that
point. Either we accept it's in the language and keep it, or we remove it
at some point, which ideally gets a deprecation first to ease migrations.
I have noticed on this list much discussion of the "minority vs. the
majority." But that is a red-herring. There are a small number of people
who have a vote (~200?) whereas there are over 5 million PHP developers and
even more PHP stakeholders who have no vote.In other words, when internals@ votes unanimously on an RFC they still
only represent ~0.004% of PHP stakeholders. Basically an aristocracy.So while a vote is a way to share an opinion, it is not representative of
the opinions of those it may affect. It is a shame that the PHP voting
process has no objective way to incorporate userland concerns except when
some act as their proxy. Which is not the same as userland having explicit
representatives with a vote.
I agree. There are a lot of unhappy user-land voices about a lot of
decisions made here. Sadly I don't see a way to give everyone a voice in
this.
Regards,
Lynn van der Berg