[PHP-DEV] Pre-RFC discussion: nameof
Hello internals, After seeing some discussions about using enum values as keys, I thought of my own implementation of `nameof` (from C#) that is very hackish: https://github.com/withinboredom/nameof I'd like to propose making it a real thing (with better behavior than my hack). An operator like this has a few niche uses, mostly for better error messages but also for making strings of things that you normally can't get the string value of. Here are some examples: nameof(func(...)) === 'func' nameof($party) === 'party' nameof($captain->planet) === 'planet' nameof(Class::Prop) === 'Prop' I first attempted this as an extension, but this belongs at the parsing/compiling level and not during runtime (this gets turned into a constant zval). I use my (very hacky) implementation to handle stringifying enums (mostly), as well as better, easier-to-refactor error messages: throw new InvalidArgumentException(nameof($var) . ' has an unexpected value'); Without it, the name of the variable can be missed in a refactor, making the error message useless or incorrect. The code to make this possible (without much error checking) is relatively simple: https://github.com/php/php-src/pull/11172 Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Current RFC process and project decisions
Hi, On Mon, 1 May 2023, 18:00 Dan Ackroyd, wrote: > On Mon, 1 May 2023 at 12:21, Jakub Zelenka wrote: > > > It seems that in the current definition, the RFC is just for blocking > > rejected features to get to the next release rather than requiring > accepted > > features to be in the next releaseIt means it requires some > > sort of consensus between core developers or at least no objections from > > some core developers. > > It might be better to think of the RFC process for new features to be > a decision on "should this feature be in PHP?" rather than a "must > this feature be in PHP?". > Yes this exactly what I was trying say. One of the reasons for this thread was actually to prevent misconception that accepted RFC is a final decision which I have feeling some voters might think. This is essentially mainly meant for technical changes where such RFC decision does not make any sense IMHO. Basically we decide about anything technical in RFC that explicitly allows leaving decision of merging for later. > As far as I can remember, there is a single RFC that wasn't merged in > the next planned release: > https://wiki.php.net/rfc/null_coalesce_equal_operator > > The vote was passed on 2016/04/02 so 7.1 was the next release version, > but it wasn't merged until 2019/01/22 and so was in PHP 7.4. > > That was due to a technical problem with the implementation - I don't > recall/understand the exact details. But it wasn't (afaik) a > controversial decision to not merge it until the patch was good > enough. > Just to clarify I don't have any problem with that. Personally I think the RFC process works fine for user facing changes and proposing changes with minimal implementation is fine in my eyes. > This was possible to happen because we don't require a complete patch > that is ready to merge. Ironing out all of the minor details for a new > feature is a huge amount of work (that people in userland are usually > completely oblivious to) which would increase the burden of passing > RFCs. > > Seeing as one of the big long term problems PHP has, is that many > contributors stop contributing after they get burnt out by doing an > RFC, I would oppose making RFCs take more work. > I agree and I would personally prefer not to do RFC for changes that are not controversial. Certainly I wouldn't want to make it worse. > Once an RFC is passed the conversation changes from whether the RFC is > a good idea or not, to being a conversation about how to best > implement it, and whether the patch has some show-stopper issues or > not. > > > This is largely undefined as almost always the core > > developers would follow the decision in RFC but technically there is > > nothing in our process that would require them to do so. > > Technically correct. Though the situation where all of the core > contributors refuse to merge a PR, probably means the PR shouldn't be > merged. > > > The idea is to maybe create a single document in the wiki collecting both > > linked RFCs with extended clarifications and maybe mirror it in git so > the > > future proposal are easier to do. > > At the risk of being a senior programmer; what problem are you trying to > solve? > The proposed single document is not meant to solve problems but improve things and make the rules clear and easy to find for new contributors. It should also remove all conflicting statements and it should also make the modification easier. > I mean, clearly there have been problems that could do with clarifying: > > * when are and what types of code cleanups allowed to happen? What > notice should be given, to avoid causing work for other developers, > who might have large existant branches they've been working on? > Yes this is exactly something that should not be addresed by the RFC IMO > > * are pull-requests that merely add comments allowed? This is > something some long-time core contributors have strong feelings about, > which I and other people disagree strongly with, but we haven't had a > framework to discuss it without shouting. > This is in some way the same as the above. Basically for me the main issue is that the RFC is the only place where conflicting technical issues between developers are decided. I think having such framework is really something that would be great to have. The TC proposal is such an attempt actually. > And there are probably other non-userland affecting code maintenance tasks. > > But as far as as I'm aware, there hasn't been a problem with an RFC > passing and the core contributors refusing to accept it. So please can > we discuss the exact problem you want to solve, so that we can agree > it's the right problem to solve, before suggesting solutions? > As I said it was mainly about improvements and making things clear at this stage which should allow further changes in the future. In terms of those chnges that I would like to see is to mainly having some framework for dealing with technical changes. Cheers Jakub >
Re: [PHP-DEV] Current RFC process and project decisions
On Mon, 1 May 2023 at 12:21, Jakub Zelenka wrote: > It seems that in the current definition, the RFC is just for blocking > rejected features to get to the next release rather than requiring accepted > features to be in the next releaseIt means it requires some > sort of consensus between core developers or at least no objections from > some core developers. It might be better to think of the RFC process for new features to be a decision on "should this feature be in PHP?" rather than a "must this feature be in PHP?". As far as I can remember, there is a single RFC that wasn't merged in the next planned release: https://wiki.php.net/rfc/null_coalesce_equal_operator The vote was passed on 2016/04/02 so 7.1 was the next release version, but it wasn't merged until 2019/01/22 and so was in PHP 7.4. That was due to a technical problem with the implementation - I don't recall/understand the exact details. But it wasn't (afaik) a controversial decision to not merge it until the patch was good enough. This was possible to happen because we don't require a complete patch that is ready to merge. Ironing out all of the minor details for a new feature is a huge amount of work (that people in userland are usually completely oblivious to) which would increase the burden of passing RFCs. Seeing as one of the big long term problems PHP has, is that many contributors stop contributing after they get burnt out by doing an RFC, I would oppose making RFCs take more work. Once an RFC is passed the conversation changes from whether the RFC is a good idea or not, to being a conversation about how to best implement it, and whether the patch has some show-stopper issues or not. > This is largely undefined as almost always the core > developers would follow the decision in RFC but technically there is > nothing in our process that would require them to do so. Technically correct. Though the situation where all of the core contributors refuse to merge a PR, probably means the PR shouldn't be merged. > The idea is to maybe create a single document in the wiki collecting both > linked RFCs with extended clarifications and maybe mirror it in git so the > future proposal are easier to do. At the risk of being a senior programmer; what problem are you trying to solve? I mean, clearly there have been problems that could do with clarifying: * when are and what types of code cleanups allowed to happen? What notice should be given, to avoid causing work for other developers, who might have large existant branches they've been working on? * are pull-requests that merely add comments allowed? This is something some long-time core contributors have strong feelings about, which I and other people disagree strongly with, but we haven't had a framework to discuss it without shouting. And there are probably other non-userland affecting code maintenance tasks. But as far as as I'm aware, there hasn't been a problem with an RFC passing and the core contributors refusing to accept it. So please can we discuss the exact problem you want to solve, so that we can agree it's the right problem to solve, before suggesting solutions? If nothing else, some problems are unsolvable by lots of documentation and bye-laws. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] PHP Technical Committee
Hi, Thanks for the feedback. On Mon, May 1, 2023 at 4:09 PM Benjamin Außenhofer wrote: > > I found this idea of a TC interesting on the outset, but after carefully > consideirng I voted no on this RFC because > > a.) i believe it to be too much bearucracy for the little benefit > I wouldn't say that having some rules in place is a little benefit but what I gather is that you and Levi, who also mentioned it, don't like forming some new entity with bunch of new rules so I guess it's probably a fair point even though I don't agree with it. > b.) potentially harmful depending on who is on the TC. > This point really saddens me as it was mentioned in all no votes reasoning and it shows that there is obviously not much trust in core devs (people that can candidate). This is not a format that would be something new and it works well for other projects (NodeJS, Python and many others) so apparently they trust more their candidates. Also the scope here is even more limited than elsewhere as I mentioned before. It's good that you provided such feedback though as it is clear that model based on maintainers wouldn't most likely work either as such risk is much higher in such model. > c.) There is also no process of overuling the TC, or voting a TC out due > to no confidence or something. Without the votes known of TC members, > voters of the TC have no insights into who they might want to boot or keep > in the next election. However introducing these data points would make > everything even more complicated. > This is a valid point and probably something that should be there. Ultimately, already at the moment each controversial change can be asked to > be RFCed and then the voters can decide with arguments made by people > knowledgable in the area. Yes, there is always some politics involved, but > the same would be true of the TC decisions. > Just to clarify this is actually not exactly correct as RFC is not meant to be used for those decisions and it has no weight unless I'm misunderstanding the currently voted rules (see my analysis in other thread). So technically RFC is just a poll for such decisions. But yeah we currently use it in such way which effectively makes some sort of undefined process. However the main problem with the RFC process is that for purely technical changes it could result in a set of rules that will limit core development. When the previous disagreement happened, it ended up with this sort of RFC: https://wiki.php.net/rfc/code_optimizations . I know that it was later withdrawn but just imaging the impact of this being accepted and honoured. And also why should something like this be decided by people that have nothing to do with a core development? That was actually one of the main triggers for this initiative and we wanted come up with something sensible that would decide those sort of things in a better way. Cheers Jakub
Re: [PHP-DEV] [VOTE] PHP Technical Committee
On Fri, Apr 28, 2023 at 12:01 PM Jakub Zelenka wrote: > Hi, > > The vote is now open for the RFC about introduction of the PHP Technical > Committee: > > https://wiki.php.net/rfc/php_technical_committee I found this idea of a TC interesting on the outset, but after carefully consideirng I voted no on this RFC because a.) i believe it to be too much bearucracy for the little benefit b.) potentially harmful depending on who is on the TC. c.) There is also no process of overuling the TC, or voting a TC out due to no confidence or something. Without the votes known of TC members, voters of the TC have no insights into who they might want to boot or keep in the next election. However introducing these data points would make everything even more complicated. Ultimately, already at the moment each controversial change can be asked to be RFCed and then the voters can decide with arguments made by people knowledgable in the area. Yes, there is always some politics involved, but the same would be true of the TC decisions. > > Regards > > Jakub >
Re: [PHP-DEV] [VOTE] PHP Technical Committee
Hi, Thanks for the feedback and explaining your no vote. That's really appreciated and would be great if other no voters could do so as well. On Sun, Apr 30, 2023 at 10:36 PM Pedro Magalhães wrote: > On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka wrote: > >> Hi, >> >> The vote is now open for the RFC about introduction of the PHP Technical >> Committee: >> >> https://wiki.php.net/rfc/php_technical_committee >> >> Regards >> >> Jakub >> > > Hi Jakob. > > Sorry for not participating in the discussion phase but I would like to > give my explanation on why I voted No. > You made a good job in distinguishing the user-facing from the technical > changes to say what can and can't be decided by the TC, but the first can't > live with the second. > Well obviously you cannot have user facing change without implementation. But you can have a general idea accepted without the implementation (or with just some base implementation showing that it might work). This is actually how the spec based languages work. Firstly the spec is created and then it is implemented. I know PHP is not a spec based language but there is no requirement for the implementation in the current RFC process. It is all just about the proposal. Of course there is a better chance to get it accepted with a good implementation done but it is not a requirement. Then, it allows the TC to have conversations and vote in private in matters > that until today have always been public. Of course developers are allowed > to talk to each other wherever they want, but what matters is said in > public. > "unless the provided implementation would result in introduction of new > bugs, side effects not mentioned in the RFC, significant performance > penalties not mentioned in RFC, or if there is an equivalent implementation > in progress that the TC finds more appropriate." is ample enough that it > can allow anything to be rejected. > > So the fact that the RFC passes does not necessarily mean that the implementation will be merged. It will most likely won't get merged if it introduces some security issues or problems that were not envisioned during the RFC process. This is just to make that decision about quality of the implementation more formal and have some process to decide it. > Overall, the idea of having a group of people that developers can ask for > some guidance from is great, but that group shouldn't have any extra rights > to block anything whatsoever. > > To demonstrate good faith and unequivocally show that this is not an > attempt at a power grab, it would be a nice gesture for the authors of the > RFC to include their withdrawal from ever holding a seat in the technical > council in the text of the RFC itself. > Well this is a collaboration effort which you can see in the linked PR. Being an author does not really mean anything here. The proposal is to have 5 people in the committee that need to be already a core developers and they react only to issues raised by other core developers. So I can't really imagine how this could significantly change things and be a "power grab". It is purely about deciding the conflicts between people that have got already powers to potentially block things. It is basically just about finding an agreement between core developers. I have just done some analysis of the current RFC process in https://news-web.php.net/php.internals/120167 where you can hopefully see that this does not take any powers from the current RFC process. Cheers Jakub
[PHP-DEV] Current RFC process and project decisions
Hi, First of all the intention of this email is to try to clarify and later better define the current RFC process and project decision processes. The ultimate goal is to have a single document that would define project bylaws and except other things be a guide for new contributors to quickly get an idea how the project decisions are done. Currently the RFC voting in defined in [1]. This defines all necessary details about a discussion, proposing changes and voting. However it doesn't say anything about the actual proposals so it can be more or less anything impacting PHP. Also it doesn't say anything about implications of the accepting of the idea (e.g. if it needs be merged) or when it should be used. There is another accepted RFC about release process [2] that defines better for what RFC should be used. Specifically it states that it should be used for the features in the following sentence: > New features or additions to the core should go through the RFC process. It is important to note that the RFC specifically states "SHOULD" and not "MUST" which is something that has been probably applied to many smaller features that didn't go through RFC over the years. It is not exactly clear if this is actually allowed as there is a conflicting note regarding release cycle that kind of says that the feature can get to the next release as long as it gets accepted: > The shorter release cycle also ensures that a given feature can get into the next release, as long as the RFC has been accepted. This could be taken that only RFC accepted feature can go to the next release which kind of conflict with the "SHOULD" above. As you can see it's pretty vague and not exactly something that has been really accepted in practice. The fact is that there is also no definition of the feature so if we took it to the extreme, it could mean any technical change would also need an RFC. I think we all agree that would be really inconvenient so that's something that we should probably better clarify. We then have rules for RMs but they are mainly based around releases. I think it would be good to define that part as well but will leave it aside for now as it is much clearer and less impacting the core development. The only important thing to note is that RM decides about bugs going to the release. It seems that in the current definition, the RFC is just for blocking rejected features to get to the next release rather than requiring accepted features to be in the next release. It means if the RFC is accepted, it can get to the next release but it does not mean that it must get to the next release. Obviously if RFC is rejected, it means that it cannot get to the next release. The implication of that is that to fully accept the feature, it requires someone to merge it and no one to revert it... It means it requires some sort of consensus between core developers or at least no objections from some core developers. This is largely undefined as almost always the core developers would follow the decision in RFC but technically there is nothing in our process that would require them to do so. In terms of conflicts between developers, the RFC does not even have much meaning because of the above. It could be used just as some sort of poll and honour the decision as such but it has no deciding factor in it. This is at least how I understand the linked RFCs so please comment if you think that the analysis is incorrect or I missed anything. I think it would be good to define this somewhere so we can potentially make tweaks into it in the future. The idea is to maybe create a single document in the wiki collecting both linked RFCs with extended clarifications and maybe mirror it in git so the future proposal are easier to do. Thoughts? [1] https://wiki.php.net/rfc/voting [2] https://wiki.php.net/rfc/releaseprocess Cheers Jakub
