Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm wrote: > > But I do agree with you. The process would have been way better if they > said “no". Or if they clearly and unanimously said “yes” which would remove > focus on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. > > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. > > // Tobias > I do not believe the reason people felt it was rushed is because of ambiguity from RMs. The reason people felt it was rushed is because: 1. It was a special case of combination types, which voters understood to be a feature targeting 8.2 2. Because it was a feature understood to be targeting 8.2, there was insufficient research into what was technically possible or favorable for general combination types. 3. Because it was a feature understood to be targeting 8.2, it had been specifically excluded from the intersection types RFC. None of those would have been addressed by anything from the RMs, because all of those have to do with the voters' understanding of what the roadmap is and what they had previously voted on. The people who had voted to include intersection types had very specifically been told that they were not nullable, and voted for it anyway, knowing that nullability would come when anticipated support for combination types came. This is my understanding of the situation, in any case. Jordan
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Tobias Nyholm wrote on 8/27/21 13:11: >>> one way of reading this proposal is that we don’t trust the release >>> managers to decide what to include and not to include in a release. >> >> To be clear, I don't trust release managers to decide that. Though >> they are all lovely people, not all of them have a deep enough >> understanding of PHP core to be fully able to evaluate changes. > > If you don’t trust the release managers to manage the release, then I suggest > you should improve the way we select new release managers. I'm not speaking for Dan here, but as one of the release managers, I don't think Dan's statement was intended to mean he doesn't trust the release managers to "manage the release." What he said is that he doesn't trust the release managers to decided what to include and not include in a release. A PHP release manager's job is narrowly defined as: > A release manager's role includes making packaged source code > from the canonical repository available according to their release > schedule.[1] That's pretty much it. That's our job. Our job is NOT to decide what goes into a release. That's the job of the voters. That said, the release schedule (which is completely within the purview of the release managers' jobs) defines dates for each release, including the feature freeze, and the release managers have the authority to change these dates, if necessary. We did not choose the change the dates in this circumstance because there was no need to change them. There were no issues requiring a change to the release schedule. >> One of the hardest things to do in an Open Source project is to say >> 'no' to someone when they are making a request that isn't completely >> unreasonable. IMO, it would have been better if the 8.1 RM managers >> had said no to opening the "Nullable Intersection types" RFC, > > Yes, but it does not mean that you *have to* say no. > But I do agree with you. The process would have been way better if they said > “no". Or if they clearly and unanimously said “yes” which would remove focus > on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. We already have this power, and we exercised this power in this particular situation, but we are also human, and we made some communication mistakes. > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. To be clear, we DO NOT have the power to veto an RFC, and this is not a power the release managers should ever have. Cheers, Ben [1]: https://github.com/php/php-src/blob/master/docs/release-process.md signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Make namespace part of runtime
> On Aug 27, 2021, at 5:07 PM, Rowan Tommins wrote: > > On 27/08/2021 20:47, Olle Härstedt wrote: >> As a followup for my previous post, I think this could be a good place >> to start to enable attribute writers to create encapsulation mechanics >> for composition, like namespace visibility, "internal" access or >> friend classes. > > > In my experience PHP projects tend to use namespace hierarchies which are > deep rather than broad, and I'm not sure how easily those hierarchies could > be re-purposed as scopes. > > Clicking through the Symfony source at random for an example, I found > "namespace Symfony\Component\Messenger\Transport\Serialization\Normalizer", > which contains only one class. I have noticed the same, including in some of my earlier PHP code soon after namespaces became available. I often wonder if those implement deep namespaces did so because "it seemed like a good idea at the time?" I have since worked hard to minimize depth of any PHP namespace hierarchy I have worked with, and as a happy coincidence it reduces the complexity of the code in the projects that use those libraries. #fwiw > A trivial implementation of namespace visibility which just matched the exact > namespace string would be completely useless for that class (it would be the > same as "private"). A slightly less trivial implementationmight allow access > from "child namespaces", but that wouldn't help in this case. > > However, it might be really useful to restrict usage of that class, or some > of its members, to classes in the "Symfony\Component\Messenger" namespace; or > maybe to those in the "Symfony\Component\Messenger\Transport\Serialization" > namespace. > > I can see two ways of enabling that: > > - Allowing visibility modifiers to specify exactly what level of prefix they > refer to. This is apparently how Scala approaches things, allowing you to > write the equivalent of "private[Symfony\Component\Messenger] $foo; > protected[Symfony\Component\Messenger\Transport\Serialization] $bar;" +1 > - Introducing a separate concept of "package", either orthogonal to > namespaces or overlapping with them, e.g. "package > Symfony\Component\Messenger; namespace Transport\Serialization\Normalizer;" > would still give a class name beginning > "Symfony\Component\Messenger\Transport\Serialization\Normalizer", but would > define "internal" to mean accessible within the "Symfony\Component\Messenger" > package. +100 > 'm personally quite keen on the idea of packages, because they're how a lot > of PHP code is developed in practice - as modular libraries linked by > Composer - and I think we could optimise the language for that use (e.g. > applying more cross-file optimisations within a fully preloaded package). Yes, agree. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Make namespace part of runtime
On 27/08/2021 20:47, Olle Härstedt wrote: As a followup for my previous post, I think this could be a good place to start to enable attribute writers to create encapsulation mechanics for composition, like namespace visibility, "internal" access or friend classes. In my experience PHP projects tend to use namespace hierarchies which are deep rather than broad, and I'm not sure how easily those hierarchies could be re-purposed as scopes. Clicking through the Symfony source at random for an example, I found "namespace Symfony\Component\Messenger\Transport\Serialization\Normalizer", which contains only one class. A trivial implementation of namespace visibility which just matched the exact namespace string would be completely useless for that class (it would be the same as "private"). A slightly less trivial implementationmight allow access from "child namespaces", but that wouldn't help in this case. However, it might be really useful to restrict usage of that class, or some of its members, to classes in the "Symfony\Component\Messenger" namespace; or maybe to those in the "Symfony\Component\Messenger\Transport\Serialization" namespace. I can see two ways of enabling that: - Allowing visibility modifiers to specify exactly what level of prefix they refer to. This is apparently how Scala approaches things, allowing you to write the equivalent of "private[Symfony\Component\Messenger] $foo; protected[Symfony\Component\Messenger\Transport\Serialization] $bar;" - Introducing a separate concept of "package", either orthogonal to namespaces or overlapping with them, e.g. "package Symfony\Component\Messenger; namespace Transport\Serialization\Normalizer;" would still give a class name beginning "Symfony\Component\Messenger\Transport\Serialization\Normalizer", but would define "internal" to mean accessible within the "Symfony\Component\Messenger" package. I'm personally quite keen on the idea of packages, because they're how a lot of PHP code is developed in practice - as modular libraries linked by Composer - and I think we could optimise the language for that use (e.g. applying more cross-file optimisations within a fully preloaded package). Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Nullable intersection types
Hi everyone, I'm happy to announce that the vote for nullable intersection types is now > open: > https://wiki.php.net/rfc/nullable_intersection_types > > It'll close in two weeks, on the 27th. > The vote is now closed with a total of 38 votes: 26 against and 12 in favor. The RFC is declined. Nicolas
[PHP-DEV] Make namespace part of runtime
Hi,
As a followup for my previous post, I think this could be a good place
to start to enable attribute writers to create encapsulation mechanics
for composition, like namespace visibility, "internal" access or
friend classes.
There's an outline to an idea by Nikic here:
https://github.com/php/php-src/pull/947#issuecomment-224934615
> In principle this should be relatively simple: Introduce a struct
> _zend_namespace { zend_string *name, uint32_t start; uint32_t end; }
> structure (where start/end are opline offsets), and store an array of these
> in the op array. Usually this array will have only a single element (or be
> empty). Generating and storing this data should be relatively simple. The
> most difficult part is probably adding support for this structure in the
> opcache optimizer (particularly the block pass), but this can later be done
> by someone else, who is familiar with the component.
The missing part is exposing it to attribute authors using a magic
constant like __NAMESPACE_RUNTIME__, reflection, or something else I
didn't think of. :)
Eventually, idiomatic attributes could be made part of the core
language as new keywords, for performance reasons (instead of
#[Internal] attribute, add an "internal" keyword, and so on).
Good idea or bad?
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Hey Dan. I see that you read what I wrote and intrepid it in the worst possible way. I will try to be more clear and more carefully chose my words in the future. I called it an “obvious mistake” because it was clear to me that we missed something. We are not bad people or worse developers because we made a mistake. We (the community) are also not shielded from making mistakes just because we have a voting process. I understand that other people are not consider it to be a mistake. That is fine. I am wrong to call it “obvious”. >> one way of reading this proposal is that we don’t trust the release managers >> to decide what to include and not to include in a release. > > To be clear, I don't trust release managers to decide that. Though > they are all lovely people, not all of them have a deep enough > understanding of PHP core to be fully able to evaluate changes. I think there are over 1000 people with “voting powers”. I assume you trust a majority of them to have this “deep enough understanding of PHP core”. If you don’t trust the release managers to manage the release, then I suggest you should improve the way we select new release managers. > One of the hardest things to do in an Open Source project is to say > 'no' to someone when they are making a request that isn't completely > unreasonable. IMO, it would have been better if the 8.1 RM managers > had said no to opening the "Nullable Intersection types" RFC, Yes, but it does not mean that you *have to* say no. But I do agree with you. The process would have been way better if they said “no". Or if they clearly and unanimously said “yes” which would remove focus on “it feels rushed” and “we can’t because of feature freeze”. This is the the extended power I would like the RMs (as a group) to have. To be clear, Im not suggesting they should veto every RFC. Just changes during feature freeze. Since RMs are experienced open source developers, Im sure they know to ask for help privately whenever they need it. // Tobias > On 27 Aug 2021, at 10:44, Dan Ackroyd wrote: > > Tobias wrote: > >> I know you are not a bad person... >> >> The fact that you unprompted (as far as I can tell) decided to in >> detail specify how RMs should make their decision about an RFC is >> giving me a strong signal that you don’t trust the role of the Release >> Manager. The timing of your RFC is also unfortunate assuming you don’t >> want to imply they are doing a poor job as they just got some criticism >> in a different thread. >> >> I may be wrong and the current and previous release managers feel like >> they really need another policy dictating their work, if so I really >> hope you worked with a few of them while you drafted this RFC. > > If you're going to call people names, you may as well do it openly, > rather than through passive aggressive phrasing like this. > > Also, if you could stop describing decisions that you disagree with as > "obvious mistakes" when the RFC author was pretty clear about the > intention, and the vote passed 30 - 3. > > Quite a few times you're giving the impression that you think other > people are dumb if they can't even see this "obvious mistake". > >> And to state something I hope is obvious: I am not accusing you for trying >> to reduce the role of Release Manager or anything else. > > You are projecting here. > > You're the person who is proposing giving Release Managers new powers > to have special RFCs where "vote should not consider “if it is too > late” or “this is rushed”." > >> To allow the release managers to have this decision power is not a >> “violation of voter rights”, that is just a silly argument. > > It's a change from what we've had before, and blowing off other > people's concerns about putting too much power in the hands of a few > people is condescending. > >> one way of reading this proposal is that we don’t trust the release managers >> to decide what to include and not to include in a release. > > To be clear, I don't trust release managers to decide that. Though > they are all lovely people, not all of them have a deep enough > understanding of PHP core to be fully able to evaluate changes. > > Coincidentally, it is explicitly listed that the Release Manager role > does not include deciding what gets shipped - > https://wiki.php.net/rfc/releaseprocess#rms_role > > "RMs Role - But they are not: Decide which features, extension or SAPI > get in a release or not" > > Nicolas Grekas wrote: >> Can you please let me know how that helps? > > It helps point out how obtuse you are being. > > Yeah, everyone gets it, there are quite a few people who commit to > Symfony who don't like that the "Pure intersection types" RFC only > implemented a pure intersection type and didn't allow a union type > with null. > > But having people from that community turn up, call people names, call > things "obvious mistakes" and try to change what feature freeze means > e.g. > >> but what is
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
Tobias wrote: > I know you are not a bad person... > > The fact that you unprompted (as far as I can tell) decided to in > detail specify how RMs should make their decision about an RFC is > giving me a strong signal that you don’t trust the role of the Release > Manager. The timing of your RFC is also unfortunate assuming you don’t > want to imply they are doing a poor job as they just got some criticism > in a different thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really > hope you worked with a few of them while you drafted this RFC. If you're going to call people names, you may as well do it openly, rather than through passive aggressive phrasing like this. Also, if you could stop describing decisions that you disagree with as "obvious mistakes" when the RFC author was pretty clear about the intention, and the vote passed 30 - 3. Quite a few times you're giving the impression that you think other people are dumb if they can't even see this "obvious mistake". > And to state something I hope is obvious: I am not accusing you for trying to > reduce the role of Release Manager or anything else. You are projecting here. You're the person who is proposing giving Release Managers new powers to have special RFCs where "vote should not consider “if it is too late” or “this is rushed”." > To allow the release managers to have this decision power is not a > “violation of voter rights”, that is just a silly argument. It's a change from what we've had before, and blowing off other people's concerns about putting too much power in the hands of a few people is condescending. > one way of reading this proposal is that we don’t trust the release managers > to decide what to include and not to include in a release. To be clear, I don't trust release managers to decide that. Though they are all lovely people, not all of them have a deep enough understanding of PHP core to be fully able to evaluate changes. Coincidentally, it is explicitly listed that the Release Manager role does not include deciding what gets shipped - https://wiki.php.net/rfc/releaseprocess#rms_role "RMs Role - But they are not: Decide which features, extension or SAPI get in a release or not" Nicolas Grekas wrote: > Can you please let me know how that helps? It helps point out how obtuse you are being. Yeah, everyone gets it, there are quite a few people who commit to Symfony who don't like that the "Pure intersection types" RFC only implemented a pure intersection type and didn't allow a union type with null. But having people from that community turn up, call people names, call things "obvious mistakes" and try to change what feature freeze means e.g. > but what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? > anything that is not yet released should be re-discussable until either > beta or RC stage. One of the hardest things to do in an Open Source project is to say 'no' to someone when they are making a request that isn't completely unreasonable. IMO, it would have been better if the 8.1 RM managers had said no to opening the "Nullable Intersection types" RFC, but I'm also pretty sure they expected you to behave better and not to throw mud around what processes the PHP does or should follow. If you want people who contribute to PHP core to ship 'more complete' features, how about getting Symfony the company (or any other company) to sponsor some of them: https://phpopendocs.com/sponsoring/internals cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Guidelines for RFC post feature-freeze
On Tue, 24 Aug 2021 at 20:02, Pierre Joye wrote: > > good evening Dan, > > First of all, could you please not merge many different mails in one single > reply? Thanks. No. This is a mailing list, where conversations get spread over different forks of threads. When a reply is relevant to multiple previous messages, it's better to combine them so people can see a complete message at once, rather than expecting people to read through multiple messages in the correct order, to understand what I'm saying. > PHP is not at a stage where what > is missing are easy additions like simple scalar return types. First, "simple scalar return types" was not an RFC, that is at least two RFCs or three: Return Type Declarations - https://wiki.php.net/rfc/return_types - 2014-03-20 Nullable Types - https://wiki.php.net/rfc/nullable_types - 2014-04-10 Scalar Type Declarations - https://wiki.php.net/rfc/scalar_type_hints_v5 - 2015-02-18 To me, this is a good example of how breaking large chunks of work is an effective strategy. Second, you are either completely forgetting or just denigrating the amount of work that was involved in getting scalar types passed. It was a shitshow of a discussion that took a huge amount of effort to get passed. Coming up with the technical details and implementing an RFC are only part of the process, and are the fun bit. But then after that any RFC author has to persuade the rest of PHP internals that it's a good idea. I talk to some of the people who do RFCs and one of the common things I hear is that listening to internals feedback is a hugely stressful and difficult thing to do. This may be different to when you last passed an RFC, at least in part because there are now relatively more people who don't commit to PHP-src frequently (or at all) taking part in discussions, and so RFC authors find it really hard to figure out which feedback should be listened to, and which feedback is less relevant. Although listening to user feedback can be useful, there is a lack of detailed technical feedback and help in implementing RFCs. > As the recent discussions show, it needs more time to design, > plan and implement the desired additions. Just saying people should work harder doesn't help. I'll agree that the project would be in a better place if there were more people making technical contributions but PHP is worked on by volunteers. But just having people show up after RFCs have been passed, and say "the work done isn't good enough" is completely disrespectful to the people who have been maintaining and improving PHP. I don't think a more difficult process is what the PHP project needs. Instead it needs more people able to, and willing to work on the code. One thing that might help with that is getting more sponsoring of people who have done work. I've made a list of RFC authors here: https://phpopendocs.com/sponsoring/internals sincerely Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility
Nikita Popov wrote on 8/27/21 10:40: >> If we don't want downstream users to redeclare the properties, why are >> they protected? >> > > To allow downstreams users to write $this->line = 123. > Got it. When I asked the question, I was thinking about passing it through the constructor, forgetting that line and file cannot be passed through the constructor. :-) Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility
On Fri, Aug 27, 2021 at 5:35 PM Ben Ramsey wrote: > Nikita Popov wrote on 8/26/21 14:57: > > On Thu, Aug 26, 2021 at 8:34 PM Ben Ramsey wrote: > > > >> Nikita Popov wrote on 8/26/21 09:57: > >>> Right. I at least do not plan to address this issue. If you take a > >>> protected property and publicly re-export it, then any compatibility > >> issues > >>> are on you. > >> > >> This does not appear to affect only cases where one is re-exporting a > >> protected property as public. > >> > >> Exception protected properties without type hints: > >> > >> * PHP <= 8.0 - https://3v4l.org/GWmrk > >> * PHP 8.1 - https://3v4l.org/GWmrk/rfc > >> > >> > >> Exception protected properties with type hints: > >> > >> * PHP <= 8.0 - https://3v4l.org/UX1Pa > >> * PHP 8.1 - https://3v4l.org/UX1Pa/rfc > >> > > > > These are not really meaningful examples, because you could simply not > > redeclare the property at all and assign it in the constructor instead > (or > > preferably, let the parent constructor assign it). That's the normal way > to > > extend exceptions. What made the original case interesting is that the > > property redeclaration isn't immediately redundant there, because it > > changes visibility. > > If we don't want downstream users to redeclare the properties, why are > they protected? > To allow downstreams users to write $this->line = 123. Regards, Nikita
Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility
Nikita Popov wrote on 8/26/21 14:57: > On Thu, Aug 26, 2021 at 8:34 PM Ben Ramsey wrote: > >> Nikita Popov wrote on 8/26/21 09:57: >>> Right. I at least do not plan to address this issue. If you take a >>> protected property and publicly re-export it, then any compatibility >> issues >>> are on you. >> >> This does not appear to affect only cases where one is re-exporting a >> protected property as public. >> >> Exception protected properties without type hints: >> >> * PHP <= 8.0 - https://3v4l.org/GWmrk >> * PHP 8.1 - https://3v4l.org/GWmrk/rfc >> >> >> Exception protected properties with type hints: >> >> * PHP <= 8.0 - https://3v4l.org/UX1Pa >> * PHP 8.1 - https://3v4l.org/UX1Pa/rfc >> > > These are not really meaningful examples, because you could simply not > redeclare the property at all and assign it in the constructor instead (or > preferably, let the parent constructor assign it). That's the normal way to > extend exceptions. What made the original case interesting is that the > property redeclaration isn't immediately redundant there, because it > changes visibility. If we don't want downstream users to redeclare the properties, why are they protected? Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] 8.1 / Exception / Property Type / Backwards compatbility
On Tue, Aug 10, 2021 at 12:55 PM Philip Hofstetter <
phofstet...@sensational.ch> wrote:
> Hello
>
> The following valid <= PHP 8.0 code that intends to make the $line property
> public is a fatal error in 8.1
>
> class FooException extends Exception {
> public $line;
> }
>
> However, the fixed code for 8.1:
>
> class FooException extends Exception {
> public int $line;
> }
>
> Is a fatal error in <= 8.0
>
> Is there a way to create a class that makes the $line property public
> that’s compatible with all versions of PHP without requiring conditional
> declaration of the class?
>
>
Not sure exactly why you need to $line property public.
If you need to be able to read it, you can use __get.
If you also need to write it, as that also worked, you can also use __set.
So an example that offers the same interface/interaction possible would be:
https://3v4l.org/tHhEL#v8.0.9
https://3v4l.org/tHhEL/rfc#vgit.master
But of course, when you look at the object with reflection, or how var_dump
prints it, the property will still be protected.
Regards,
Alex
