> On Oct 9, 2019, at 4:25 AM, Lynn <kja...@gmail.com> wrote: > 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).
I will address the question of perspective below. > 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. There is not logical/logistical/technical reason why we cannot deprecate w/o a plan to remove. The only reason is that you and maybe others have established the constraint in your mind(s) that it is a requirement. And that is unfortunate, because there is absolutely nothing that would stop us from deprecating something with no current plan to remove. But I am not challenging you. People do this all the time in areas they care about. They establish constraints that only exist in their mind. I could give multiple example of where that happens in governmental politics, but I won't for fear of offending someone who has set constraints in their mind about any given example topic. Instead I am asking you to be willing to find a workable solution and ask yourself this: Is this constraint which only exists in your attitude towards to topic really so important that we cannot consider revisiting it, especially if it will allow the PHP team to signal users not to use a disliked feature but also ensure that no userland code won't break? The tangible benefits here seem to be to outweigh the intangible constraints. And please note, there is nothing that stops a future RFC from remove a feature at a future date assuming the community agrees that the BC concern for this feature is no longer the overriding concern. But to force a constraint that does not actually exist feels like we are tying one hand behind our back prior to a fist-fight. Especially when making sure we have all available hands can potentially reduce the acrimony of these non-stop BC debates. > 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. I do see a way to give userland a voice, and I have written up significant parts of a proposal for this, but it is far from complete. In a nutshell we could create a PHP userland advisory board to parallel internals, complete with it's own list named `userland@`. As a straw man proposal there could be a set number of seats (~250?), divided up by how they are involved in PHP; corp developer, independent developer, framework vendor, hosting company, etc. They should participate as representatives of userland rather than as representatives of their own opinions. They would get to vote on things so we could gauge userland's interests, but their vote could only be used to veto an accepted RFC, and internals@ could override the veto if, say, 90% of internals@ members voted to do so. We could also have requirements for these delegates to contribute in areas such as documentation, testing, and for those who are representing commercial interests, possibly even sponsorship funds (although this latter would require an entity to receive those funds and AFAIK that entity does not currently exist.) And this could reduce traffic on the internals@ list as debates that affect userland could move to userland@ list. The only thing left about this proposal is actually how to implement it, which is something that a working group of people could get together and create a proposal. Assuming there are enough people that would embrace the idea to create said working group. -Mike
