On Tue, Oct 8, 2019, at 6:26 PM, Stanislav Malyshev wrote: > Hi! > > > If you feel you want all those functions deprecated in favor of any other, > > put up a RFC whenever you want to(No one is stopping you from that). > > That's part of the problem. RFC should be for something that is > necessary and beneficial for the whole community, doubly and triply so > when we're talking about BC breaks. It shouldn't be just "whatever I > want, let me put it to a vote". RFCs are not a twitter poll where > anybody can vote on anything and anything goes. It should be used > responsibly, and if people don't understand this responsibility maybe > it's too early for them to propose any RFCs. > > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
I hesitate to wade into this discussion at all, but I have to overall agree with Zeev and Stas. I'm a vocal proponent of PHP evolving, becoming "stricter" (whatever that means), more typing, adopting more modern/functional features, not being held back, blah blah blah. Normally I'm on the side of the language itself becoming more powerful. I... had actually forgotten that backticks existed until this thread, to be honest. I can't recall the last time I used them. But, on this point Zeev is correct: There are a few billion lines of PHP code in the wild, and we only know what's used in maybe a few million of them. That means the barrier for removing a feature needs be *really* high, and "it seems confusing" does not clear that bar. "If we were designing the language today we wouldn't do that" is also not a compelling argument. "Programming is like sex; make one mistake and support it for the rest of your life." (Anonymous.) That something is already implemented has a larger vote than whatever design preferences we may globally have. BC breakage in a language is a big frickin' deal. It should not be taken lightly, and "people don't know what to google for" is, frankly, very lightly. Overall, I see only three good arguments for BC breakage: 1) Security. 2) It's rarely used AND it conflicts with some other significant improvement. 3) It's rarely used AND it is a very common source of serious bugs (even if not technically security). (Note: Technically adding a new function or class is also a BC break as it reserves a new function/class name, and we should be cautious with those, but that's a lower threshold in my mind as it doesn't change existing behavior except in very narrow circumstances that will be immediately discovered and have a very natural way to address them.) There absolutely are issues that rise to that level. register_globals and magic quotes are the canonical examples, but the last minute change of random_int() to throw an exception rather than return false when it can't generate a true random value is also in that category. So far, I have not seen any arguments for deprecating/removing backticks that meet that criteria, nor data to suggest that they do. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
