Le lun. 23 août 2021 à 16:22, Larry Garfield <la...@garfieldtech.com> a écrit :
> On Sun, Aug 22, 2021, at 5:42 PM, Patrick ALLAERT wrote: > > > Either extra time, or having a way to influence the schedule of the > > releases. > > For now, we work with a fixed schedule and don't know (at least: me) how > > strict we must stick to it. > > > > The fixed schedule of the releases is what makes me more comfortable with > > the idea of reverting a new feature rather than extending the scope of > one. > > Speaking from the outside: > > Joe stated in an earlier email very clearly that because this was viewed > as a "possible bug fix" it was given permission to run post-freeze. There > was no dispute in my mind at least whether the RFC was valid. > > That said, if voters are of the opinion that "the cure is worse than the > disease" on this one (eg, because it didn't take into account larger > questions around compound types that will have to come later, and so may > make things more difficult in the future, or because the reflection API > isn't fully thought through, etc.), or that it feels too rushed, that is > entirely their right to vote no on it on those grounds. That's basically a > summary of my No vote: I'd rather have non-nullable intersections for now > than something that is going to make life more difficult in the future for > full mixed types. > > > > > Based on the partial results of the vote, we could conclude that the > > > consensus is to 1. not allow nullability and 2. force bracket around > > > (X&Y)|null. I can't read this as anything else than ppl voting not on > the > > > RFC, but on this metadiscussion about the feature freeze + some fear > that > > > we might put ourselves in a corner with the syntax. > > > > > > The RFC should be allowed to complete, it's gathering important data. > > >> > > > > > > Because of what I just wrote about, I don't think we can rely on any > data > > > here. The discussion should be rebooted from scratch for me. > Apparently, we > > > need the full syntax for composite types to decide for the syntax for > > > nullable intersection types. ¯\_(ツ)_/¯ > > > > > > > I also think that we can't rely on the data for the reason you mention > even > > if I intended to vote "no" on the feature, not on the targeted version of > > PHP, I may be the exception there. > > That's not different than any other RFC. We never differentiate "no on > the concept" from "no on the implementation" from "no on some particular > detail that's really really important." That's data we almost never get, > unless someone volunteers it on their own. This RFC is no different in > that regard. > > > > Now, I don't know what to do. The vote started and is not looking good > for > > > the proposal. Some will say that I didn't want to see it fail if I > withdraw > > > it. But honestly, with all those interferences, I'm not sure the > conditions > > > are met to have a fair vote. > > I have to disagree. Given Joe's earlier message, the RFC was legal and > allowed to proceed. "I still think it's too late" is entirely someone's > right to justify a No vote. That's not interference, that's the voter's > viewpoint and it should be respected. > No need to disagree as I was referring to exactly that: the legality of the vote. This legality has been deeply challenged during the discussion period and during the vote itself. That's what I'm referring to as interference. Once the legality is shielded, of course ppl are free to vote what they want. That wasn't the case at all for this RFC. I wish we'll find a way to not experience this confusion anymore in the future. Nicolas
