Le mar. 24 août 2021 à 08:09, Pierre Joye <pierre....@gmail.com> a écrit :
> Hi Marco, > > On Tue, Aug 24, 2021 at 3:49 AM Deleu <deleu...@gmail.com> wrote: > > > > Hello everyone! > > > > We recently had the Nullable Intersection Types RFC process in an > > unconventional way starting a new RFC post feature freeze. If memory > serves > > me right, another similar incident happened with the Attributes RFC which > > had a syntax that could not be implemented without a secondary RFC [1] > and > > went through a secondary RFC which proposed a different syntax [2]. > > > > [1] https://wiki.php.net/rfc/namespaced_names_as_token > > [2] https://wiki.php.net/rfc/attributes_v2 > > > > I would like to gather opinion on a potential Policy RFC that would > define > > some guidelines for such a process. As Nikita pointed out [3], the > ability > > to refine new features is both important for the developer and > undocumented > > for the PHP Project. > > > > In order to not be empty-handed, I started a gist that can be seen as the > > starting point for this discussion, available at > > https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105. > > > > Generally speaking, I'm first looking for feedback on whether this is > > something that deserves attention and an RFC or is it so rare that it's > > fine to leave it unchanged. If there is interest in moving forward, I > would > > then also be interested in suggestions on things that should be > > included/excluded in the RFC. > > It is a very good text, thank you! > > It is also much needed, generally speaking. What I would add is about > what is allowed to begin with. I would rather restrict to fixes only. > > The other issue, which is the one Nicolas suffered from, incomplete > addition to begin with. Incomplete in the sense of, "We add feature A, > but behaviors A1 and A2 are not supported and can be done later". > > Many additions went through while being incomplete. It was documented > so in the RFC but it does not make it a good thing. Many of them are > indeed much needed and related to features (some) PHP users have been > waiting for. Are they critical enough for the PHP usage to allow them > in while knowing it is not complete? For almost all recent RFCS > related to syntax, arguments/return types or properties, I don't think > it justifies being added while being incomplete. It is not critical > enough to the larger user base. It makes migration paths harder as > well. > > A library or framework (main users of most of these features) may or > may not implement the given addition, requiring say 8.1, and yet again > require 8.2 and redo the implementation to support (hopefully) the > full features. > > This is a path I dislike, I may have a different view on the big > picture, however I do think we rushed too many of these features too > early. A vote does not solve this problem given the limited amount of > votes we can see. > Thanks for writing this Pierre, I wholeheartedly agree with this. This was the fundamental trigger to my RFC: trying to make intersection types closer to general usefulness *in*my*opinion*! (I don't want to reopen the topic :) ) I would welcome a new RFC to clarify what is allowed during the feature freeze. As I wrote in another thread, my opinion is that anything that is not yet released should be re-discussable until either beta or RC stage, at least for simple changes (I wouldn't have submitted my RFC if the patch wasn't trivial from a technical pov.) WIth the current feature freeze schedule, I realize that there is little to no room for userland to play with a feature-full binary before it's too late to give feedback. I experienced this when I was objected that the RFC was 4 months old already. I can't keep up with testing all RFCs. But if there is a clear window where such feedback is welcomed, I would happily use it. I think others would too. Nicolas
