On Fri, Aug 16, 2019 at 12:08 PM Mark Randall <mar...@gmail.com> wrote:
> On 16/08/2019 11:18, Christoph M. Becker wrote: > > It is not necessarily required to have an implementation for an RFC > > available, see item (6) in <https://wiki.php.net/rfc/howto>. > > I have enormous respect for Derick, but I can't help but feel this "RFC" > was bodged from the start. > > There's certainly a place for straw polls, the ability to receive quick > feedback on opinions and sentiment can be a positive thing in a lot of > circumstances. This however, seemed more like an invitation for > internals developers to express that they wouldn't entertain spending > any time on the proposal, in effect forcefully slamming the door shut on > it before a proper discussion had been had. > > The end result did seem to be like watching Zeev be thrown to the lions > in the colosseum. While entertaining for a short time, I believe it left > something of a sour taste in the mouth, and it certainly did not present > internals well to the outside world. The hasty edits to the Wiki then > made it worse, and so on. > > I agree (although I didn't really find it entertaining for a short time). As I said (or at least tried to say) in my previous comments on this thread, I don't think Zeev's ideas were necessarily bad, just unwarranted at this time. Unless I'm misunderstanding him, I think he, at least somewhat, feels that way as well. He sees some issues coming down the road and made this proposal as an attempt to prevent them. Others, myself included, seem to feel that the problems he foresees aren't going to happen, or at least aren't inevitable. As such, I wasn't so much saying that P++, editions, or other similar ideas are totally off the table forever and ever... just that we should wait until we reach a point where one of them is necessary, since there is a good chance we won't ever reach that point. I encourage Zeev to continue refining and fine tuning his ideas, so that if we do reach that point, we can hit the ground running. Until then, I think any discussion on this mailing list goes beyond the level of "informal" and takes focus away from advancing the language. > I believe for anything remotely positive to come out of this whole > affair, things need to quickly and visibly pivot to a meaningful > discussion about the long term game plan for PHP, and build a consensus > on things such as strict typing, overloading in the core functions, and > perhaps most divisively, if "cleaning up the language" is in itself a > viable justification for backwards compatibility breaks, and if so, what > weight it should carry. > > I personally don't see this as necessary. I think it's safe to say that anything is on the table. Every change needs to properly weigh the positives and negatives. A new feature might be in high demand and cause no BC issues, but, the resources required to build it prevent 10 other slightly less highly demanded features. As was mentioned earlier, a lot of the more sought after features (union types, enums, annotations, etc) don't require BC breaks at all. What's holding them back isn't a lack of vision or purpose either - it's the difficulty of implementing them. A BC break to clean up the language might be justified in one case, and not in another. To make a blanket statement that we will or will not attempt to clean up the language is not wise in my opinion. It puts the project in a bad place if it's forced to stick to it's decision, or, it makes the whole reason for having made a decision pointless if we keep finding certain items that are exceptions. > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
