Re: [PHP-DEV] [RFC] path_join function
On Wed, May 17, 2023 at 11:13 AM Timo Tijhof wrote:
> In case it is of interest, the implementation we use on Wikipedia
> as part of MediaWiki, is available on Packagist:
>
> https://packagist.org/packages/wikimedia/relpath
> https://www.mediawiki.org/wiki/RelPath
>
> --
> Timo Tijhof,
> Wikimedia Foundation.
> https://timotijhof.net/
>
>
>
> On Wed, May 17, 2023 at 3:54 PM wrote:
>
> > Hey,
> >
> > I have created on GitHub a feature request for a path_join function (
> > https://github.com/php/php-src/issues/11258) and got the label that this
> > requires a RFC. So I am here now :)
> >
> > The idea is to provide in PHP itself a function to join filesystem paths
> > (idea: path_join) like in other languages, node as example (
> > https://nodejs.org/api/path.html#pathjoinpaths). For me this function is
> > some kind of base filesystem functionality like basename, realpath.
> >
> > Example usage:
> >
> > path_join('/base', 'my', 'path'); // /base/my/path
> > path_join('/base', 'my', 'path', 'test', '..'); // /base/my/path
> >
> > Why not just string concatenation?
> >
> > When you concat just the paths you have to think about:
> > - normalize string part to strip ending slash
> > - for windows compatibility you have to use DIRECTORY_SEPERATOR
> >
> > I think this can improve the developer experience when working with
> > filesystems a lot and people can delete their implementation.
> >
> > I am really looking for your feedback, right now I have no “karma points”
> > to create a RFC in the wiki :)
> >
> > Thanks,
> > Soner
>
Definitely a useful feature, but not sure it needs to be a core function.
It's very easy to implement in userland. Userland implementation also
allows people to better customize it to their needs. Never going to be
using it on windows? Just use /. Only going to be using it on windows? Just
use \. Need to support URLs as well as windows directories, create a method
that allows specifying the separator. Just for the simple case of windows
vs *nix directories, how is it determined which separator to use? If it's
the operating system that the code is running on, then what about if I need
to generate a *nix style path even though I'm running on Windows, or vice
versa? My feeling is that for the function to be easy to use, you have to
cut out too many scenarios which causes users to have to fallback to their
own implementations anyway. Finally, there aren't going to be any
meaningful performance gains which would possibly justify not implementing
it in userland.
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] RFC: rules for #include directives
On Mon, Jan 16, 2023 at 7:54 AM Max Kellermann wrote: > On 2023/01/16 13:38, Kamil Tekiela wrote: > > Did you create an RFC already? Or is this RFC-like discussion? > > No. I followed https://wiki.php.net/rfc/howto and this is step 1. > Creating the actual RFC is step 3. > > (I'm new to PHP and this process - so far, I've only contributed PHP > code through GitHub, and I was surprised by today's sudden resistance > against my code cleanup by two PHP developers, after the others > welcomed by changes.) > > > In either case, if you are asking community to come to a decision, we > need > > to see some background. > > > Why do you want to change this? What's the benefit? > > For cleaner code, more readable code (less obscurity in huge amounts > of undocumented #includes), more correct code, less fragile code, > reduced compile times. > > > What's the impact on other maintainers, especially extension > > maintainers? > > Other maintainers may need to determine which includes they really > need, instead of relying on everything always already there by > including one random zend_* header. > > Extension maintainers may see build failures because, for example, > they forgot to include errno.h but used "errno". This previously > worked because all PHP headers included errno.h even though there was > no reason to. These build failures are bugs in those extensions, and > revealing them is a good thing, even though it seems tedious at first. > > > Do you see any downsides to your new approach? > > Like any code cleanup, this can result in regressions for parts of PHP > that are not covered by a test and not built with the CI, like the > DTrace regression yesterday. > > And code cleanups can easily reveal existing bugs, which is a good > thing, but those bugs can be hidden at first - e.g. failure to > explicitly include "php_config.h" will (silently) disable features and > break things. That may cause some temporary pain, but in the end will > result in better code, though some will believe that it isn't a worthy > goal or not worth the temporary pain. > > Derick Rethans wrote my idea "adds nothing but clutter", but I guess > he should explain what bothers him; I don't comprehend this, because > from my perspective, I intend to remove clutter. > > Dmitry Stogov said it's "just a useless permutation", but I can't > understand this argument either. > > Max > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > For those of us that don't know the finer details of the build process, will that have any impact on the final product such as reduced binary sizes or better performance? I'm not saying that code cleanup isn't a good enough reason to do this on its own, just curious if there are other advantages beyond that. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Adding new closing tag =?> for keeping trailing newline
On Wed, Jun 8, 2022 at 5:37 AM Claude Pache wrote: > > > > Le 8 juin 2022 à 05:34, Sara Golemon a écrit : > > > > > > > declare(ignore_newline_after_close_tag=false); // defaults to true, i.e > > existing behavior > > > > This would avoid any new syntax rules, but still provide the ability for > > php-as-template-engine to behave in the user's preferred mode. > > > > No, because the user’s preferred mode is not a global one, it is a local > one. You do not want to keep newlines in the following situation: > > ``` > * line 1 > > * line 2 > * line 3 > > * line 4 > ``` > > With a global switch, not only you have failed to solve the real problem > (doing the Right Thing with newlines), but also you have created another > one (looking at the top of the file in order to understand the code). You > have the worst of both world. > > Declare statements shouldn't have any impact outside of the file in which they appear. Declaring strict types doesn't force other classes that interact with the defined class to also use strict types. A declare to change how newlines after closing tags are handled within a single file forces anything that uses the classes/functions defined in that file to know that it handles them in a possibly different ways. I personally don't see a need for a new closing tag. I'm not usually swayed by the "it adds confusion to the language" and would be against removing such a tag if it existed and that was the reason for removing it. However, I do think it's something to consider when adding something new to the language. In this case, I don't think the positives outweigh the negatives, especially in light of the fact it's really easy to accomplish this without changes. > —Claude > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown
wrote:
> On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm
> wrote:
>
> > On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
> >
> >> Hi everyone
> >>
> >> I'd like to start discussion on a new RFC for arbitrary string
> >> interpolation.
> >> https://wiki.php.net/rfc/arbitrary_string_interpolation
> >>
> >> Let me know what you think.
> >
> > That is a cool idea.
> > But I am not a big fan of having code in strings.
> > Wouldn’t this open the door to all kinds of new attacks?
>
> Do you have an example of a new kind of attack this would allow?
> The proposal doesn't enable interpolation of strings coming from
> a database or user input - it only applies to string literals
> directly in PHP code.
>
> Personally I'm really looking forward to having this functionality.
> Just a couple days ago I wanted to call a function in an interpolated
> string, and it was really annoying to have to wrap the function in a
> closure in order to use it.
>
> If this RFC is accepted I'd be able to replace code like this:
>
> $name = "Theodore Brown";
> $strlen = fn(string $string): int => strlen($string);
> echo "{$name} has a length of {$strlen($name)}.";
>
> with
>
> $name = "Theodore Brown";
> echo "{$name} has a length of {$:strlen($name)}.";
>
>
Out of curiosity, why not:
$name = "Theodore Brown";
echo "{$name} has a length of ".strlen($name).".";
or even
$name = "Theodore Brown";
$len = strlen($name);
echo "{$name} has a length of {$len}.";
>
> Sincerely,
>
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Regarding Russia invasion on Ukraine
On Sun, Mar 13, 2022 at 4:43 PM Kris Craig wrote: > On Sun, Mar 13, 2022, 1:36 PM Larry Garfield > wrote: > > > On Sun, Mar 13, 2022, at 3:14 PM, Wojciech Lisik wrote: > > > Hello all, > > > > > > am writing here because this topic > > > <https://externals.io/message/117187> has been locked. > > > > > > I condemn with whole my heart what Russia is currently doing - no > > > questions asdked. > > > > > > But I also think that - in light of current multinational sanctions > > > against Russia - > > > > > > * all core-team devewlopers of PHP that are of Russia nationality > > > should be banned, > > > * their contributions should be removed, > > > > > > from whole php org on GitHub. > > > > > > I fully understand that removing contributions of such users like > > > *nikic *will break php as a script, but I think that this is the only > > > viablle way to protest against what Russia is doing; to show that > > > Russian people are welcomed no more anywhere. > > > > > > Pozdrawiam, > > > Wojciech Lisik > > > > > > Wysłano z bezpiecznej poczty e-mail ProtonMail < > https://protonmail.com/>. > > > > > Attachments: > > > * signature.asc > > > > This is beyond absurd to the point that I have to assume you're trolling, > > because the alternative is that you are both intensely racist and > intensely > > stupid. Or perhaps all three. > > > > Normally I would advocate for a gentler touch when someone says something > > wrong, but this is so far beyond rational that it doesn't deserve a > gentle > > response. > > > > --Larry Garfield > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > 100% agree with Larry. Banning people from PHP based solely on their > ethnicity is easily the stupidest, most blatantly racist idea I have ever > seen proposed here. > > Absolutely shameful. > > > > I took this as a satirical take on how many other sectors are reacting to Russian invasion, not an actual position being advocated for. > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Sun, Mar 6, 2022 at 5:32 PM Kris Craig wrote: > > > On Sun, Mar 6, 2022, 12:53 PM Chase Peeler wrote: > >> >> >> On Sun, Mar 6, 2022 at 3:40 PM Kris Craig wrote: >> >>> >>> >>> On Sun, Mar 6, 2022, 12:36 PM Chase Peeler >>> wrote: >>> >>>> >>>> >>>> On Sun, Mar 6, 2022 at 3:23 PM Kris Craig wrote: >>>> >>>>> On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov >>>>> wrote: >>>>> >>>>> > On Sat, Mar 5, 2022 at 14:26, Kris Craig >>>>> wrote: >>>>> > >>>>> > Specifically, I would direct this question to Pierre and Viktor: Do >>>>> you >>>>> > believe that "Arrest Dictator Putin" is appropriate for the PHP >>>>> homepage? >>>>> > >>>>> > >>>>> > As a Russian who fled his country because of arising concerns over >>>>> Mr. >>>>> > Putin's regime, I find any words against him, appropriate. I'm a >>>>> pacifist >>>>> > but I probably would try to kill him if I was given a chance. >>>>> > >>>>> > Speaking about how appropriate "Arrest Putin" would be *on the PHP >>>>> home >>>>> > page*, I'd say no, because I see how many different people have >>>>> gathered >>>>> > here. We see that even Ukranian flag on PHP homepage is going to >>>>> cause >>>>> > tensions (what about Iraq & Viet Nam?). >>>>> > >>>>> > Starting this discussion, I had in mind the "sanity again madness" >>>>> > mentality. I even feel sorry now for how this thread brings so many >>>>> > disagreements and sol little compromise, so many emotions and so >>>>> little >>>>> > reason. I still think though that in times like this, stating >>>>> something >>>>> > like "PHP is against war" is very timely, and it is something we can >>>>> agree >>>>> > to, without destroying any connections within community. >>>>> > >>>>> >>>>> +1 for a banner that says "PHP is against war". I would have >>>>> absolutely no >>>>> objection to that one. >>>>> >>>> As I’ve said before, I would have a problem with this. War is terrible >>>> and should be avoided at all costs. However, there are times it is >>>> justified. >>>> -- >>>> Chase Peeler >>>> chasepee...@gmail.com >>>> >>> >>> In that case, I think we should scrap this idea altogether. I mean, if >>> we can't even agree that war (i.e. institutionalized mass murder) is a bad >>> thing, then there's no statement we could make on this that wouldn't divide >>> our community. >>> >>> I agree we should scrap this for the many reasons people have given >> earlier. However, you are misquoting me. I said war was a terrible thing. >> Sometimes, though, the alternative is worse. I point you to WW2. How many >> more would have died in the holocaust if the allies had not gone to war >> against the axis powers? >> -- >> Chase Peeler >> chasepee...@gmail.com >> > > From a philosophical perspective, it could be argued that the war was > already underway. And since Hitler started that war to conquer, I would > argue that WWII, like every other war, was unnecessary. > If no one had fought back, would it have really been a war? > > That's not to say it wasn't necessary for the allies to get involved. But > we didn't start that war, and it most certainly was not necessary for > Germany to invade Poland. > Exactly my point. We can say we are against war as much as we want, but there are evil people in this world that will still prey on others. When that happens, “good men” are sometimes forced to fight back. > Fighting a war to end a war is one thing. Starting a war, on the other > Yep. So you’ve already made caveats to your absolute statement, which was my point. > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Sun, Mar 6, 2022 at 3:40 PM Kris Craig wrote: > > > On Sun, Mar 6, 2022, 12:36 PM Chase Peeler wrote: > >> >> >> On Sun, Mar 6, 2022 at 3:23 PM Kris Craig wrote: >> >>> On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov >>> wrote: >>> >>> > On Sat, Mar 5, 2022 at 14:26, Kris Craig wrote: >>> > >>> > Specifically, I would direct this question to Pierre and Viktor: Do you >>> > believe that "Arrest Dictator Putin" is appropriate for the PHP >>> homepage? >>> > >>> > >>> > As a Russian who fled his country because of arising concerns over Mr. >>> > Putin's regime, I find any words against him, appropriate. I'm a >>> pacifist >>> > but I probably would try to kill him if I was given a chance. >>> > >>> > Speaking about how appropriate "Arrest Putin" would be *on the PHP home >>> > page*, I'd say no, because I see how many different people have >>> gathered >>> > here. We see that even Ukranian flag on PHP homepage is going to cause >>> > tensions (what about Iraq & Viet Nam?). >>> > >>> > Starting this discussion, I had in mind the "sanity again madness" >>> > mentality. I even feel sorry now for how this thread brings so many >>> > disagreements and sol little compromise, so many emotions and so little >>> > reason. I still think though that in times like this, stating something >>> > like "PHP is against war" is very timely, and it is something we can >>> agree >>> > to, without destroying any connections within community. >>> > >>> >>> +1 for a banner that says "PHP is against war". I would have absolutely >>> no >>> objection to that one. >>> >> As I’ve said before, I would have a problem with this. War is terrible >> and should be avoided at all costs. However, there are times it is >> justified. >> -- >> Chase Peeler >> chasepee...@gmail.com >> > > In that case, I think we should scrap this idea altogether. I mean, if we > can't even agree that war (i.e. institutionalized mass murder) is a bad > thing, then there's no statement we could make on this that wouldn't divide > our community. > > I agree we should scrap this for the many reasons people have given earlier. However, you are misquoting me. I said war was a terrible thing. Sometimes, though, the alternative is worse. I point you to WW2. How many more would have died in the holocaust if the allies had not gone to war against the axis powers? -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Sun, Mar 6, 2022 at 3:23 PM Kris Craig wrote: > On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov > wrote: > > > On Sat, Mar 5, 2022 at 14:26, Kris Craig wrote: > > > > Specifically, I would direct this question to Pierre and Viktor: Do you > > believe that "Arrest Dictator Putin" is appropriate for the PHP homepage? > > > > > > As a Russian who fled his country because of arising concerns over Mr. > > Putin's regime, I find any words against him, appropriate. I'm a pacifist > > but I probably would try to kill him if I was given a chance. > > > > Speaking about how appropriate "Arrest Putin" would be *on the PHP home > > page*, I'd say no, because I see how many different people have gathered > > here. We see that even Ukranian flag on PHP homepage is going to cause > > tensions (what about Iraq & Viet Nam?). > > > > Starting this discussion, I had in mind the "sanity again madness" > > mentality. I even feel sorry now for how this thread brings so many > > disagreements and sol little compromise, so many emotions and so little > > reason. I still think though that in times like this, stating something > > like "PHP is against war" is very timely, and it is something we can > agree > > to, without destroying any connections within community. > > > > +1 for a banner that says "PHP is against war". I would have absolutely no > objection to that one. > As I’ve said before, I would have a problem with this. War is terrible and should be avoided at all costs. However, there are times it is justified. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Fri, Mar 4, 2022 at 8:53 PM Michael Morris wrote: > On Wed, Mar 2, 2022 at 3:31 AM Victor Bolshov > wrote: > > > Hello internals. > > > > In these dark days for humanity, we as people of civilization, people > > of sanity, kind and caring people with children and families - we have > > to speak up, loud and clear, in support for Ukraine. To stop Russian > > aggression. > > > > I suggest to add Ukranian flag and a supportive anti-war disclaimer to > > the header of php.net website. > > > > Why is this important? There are a lot of PHP developers in Russia. A > > lot of them, sadly, have been brainwashed by Putin's propaganda. They > > still must have a lot of respect to PHP authors and creators. Seeing > > that these people, who have their respect, are against the war and for > > the freedom of Ukraine, might have an impact. > > > > This is not the time to "stay away from politics", we are experiencing > > an attack on humanity itself. Take example from > > <https://junit.org/junit5/> and their clear statement. > > > > Say NO to war! > > > > This original post has been met with some controversy. I don't know how > much my voice counts, but I will say this. > > The occasions in history where one side is utterly and completely in the > wrong are rare, but they do occur. Russia had no right to invade - period. > Attempts on this list have been made to justify Russia's actions, but they > are logically tortured as the Nazi justifications for invading Poland or > Soviet Russia. Maybe I missed them, but I don’t recall anyone justifying Russias actions. Can you cite them please? > > Speaking of the Nazis, even Hitler didn't stoop so low as to send in troops > utterly unprepared for what they were about to face while lying to them > that they'd be lauded as heroes. Neither did Stalin. Putin has done that. > > Now, you can try to justify certain things. You can try to justify Putin's > War, but you will never convince anyone of your position - you can only > succeed in proving yourself to be evil. Evil is the complete absence of > compassion for the suffering of others, and only someone who is evil can > advocate for Putin's War or try to justify it in any measure. > > Evil is a powerful word - one I do not use lightly. When one side calls > another evil they say that there can be no more dialog, no more compromise, > no more cooperation. The only correct response to evil is opposition. > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Thu, Mar 3, 2022 at 12:56 PM Eugene Sidelnyk wrote: > All the world currently talks about the situation in Ukraine. Everyone who > knows the truth are trying to help stop invasion. The main problem here is > that most of Russian people believe in Putin's political position. Moreover > they will have Instagram and Twitter blocked soon in Russia so that they > won't be able to know the real state of things. > > Therefore our responsibility is to bring the truth to Russian people and > they will do the rest. PS. 70% of surveyed people support Putin. How else > we can inform them of what is really going on if not writing about it > everywhere? > > A banner on php.net isn't going to change their minds > If you, as PHP community, do not do anything about it, it would mean that > you don't care. Well, everyone who writes php internals is for discussion > of php internals only doesn't care and probably won't. > > This is the kind of language we need to avoid. Don't accuse people of not caring just because they don't agree with how to approach the issue. > > > On Thu, Mar 3, 2022, 5:49 PM Arvids Godjuks > wrote: > > > On Wed, 2 Mar 2022 at 11:31, Victor Bolshov > wrote: > > > > > Hello internals. > > > > > > In these dark days for humanity, we as people of civilization, people > > > of sanity, kind and caring people with children and families - we have > > > to speak up, loud and clear, in support for Ukraine. To stop Russian > > > aggression. > > > > > > I suggest to add Ukranian flag and a supportive anti-war disclaimer to > > > the header of php.net website. > > > > > > Why is this important? There are a lot of PHP developers in Russia. A > > > lot of them, sadly, have been brainwashed by Putin's propaganda. They > > > still must have a lot of respect to PHP authors and creators. Seeing > > > that these people, who have their respect, are against the war and for > > > the freedom of Ukraine, might have an impact. > > > > > > This is not the time to "stay away from politics", we are experiencing > > > an attack on humanity itself. Take example from > > > <https://junit.org/junit5/> and their clear statement. > > > > > > Say NO to war! > > > > > > > > > > As someone from Baltics and living there still - yeah, colour be yellow > and > > blue all the way. > > > > But I also think we should leave php.net out of it - this is not a > project > > with a core tea - this is a very distributed project that probably > touches > > almost every single country on this planet. > > > > Another reason - just look what happened to the React's issue tracker: > > https://github.com/facebook/react/issues - you can bet your life on it > > that this will happen to the PHP project as soon as there is anything on > > this topic done. Does the project has resources to deal with it? I mean, > > this is basically a DDoS that can be solved only by closing off issue > > creation from public. > > > > It's just impractical and will ruin maintainers and contributors ability > to > > do their work for the foreseeable future. > > -- > > > > Arvīds Godjuks > > +371 26 851 664 > > arvids.godj...@gmail.com > > Telegram: @psihius https://t.me/psihius > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Wed, Mar 2, 2022 at 12:03 PM Alain D D Williams wrote: > On Wed, Mar 02, 2022 at 05:43:25PM +0100, Victor Bolshov wrote: > > Just one more thing: as of yesterday, in response to western sanctions > and > > supplies of letal arms to Ukraine from EU countries, Putin has ordered > > Russian nuclear forces to switch to a special alert regime, which means > they > > will be ready to strike at any moment. Anything that can help stop this > > insanity, is welcome, IMO. > > How Putin will react to a banner on the PHP web site, or any other action, > is > anybody's guess. > > I'm pretty confident I can guess how he will react: he won't. > I have put something on my own web site. It is an expression of solidarity > with > Ukraine - something to encourage them. It Putin/Russia notices it I suspect > that it will only invite a DDOS attack or similar - if they do anything at > all. > > The big question: should there be something on the PHP web site. Hard to > answer > as the discussion has shown. I would say "no" but encourage everyone who > has a > personal site to do so and to raise discussion with their employer about so > doing. > > Maybe also help financially (eg URL below), but beware: scammers will have > set > up sites like this: > > https://www.donateukraine.com/ > > Personally: I am in my late 60s and this is bringing back unpleasant > memories > of my 20s when we were seriously concerned about impending destruction from > nuclear war. > > Hugs to all in these difficult times. > > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT > Lecturer. > +44 (0) 787 668 0256 https://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: > https://www.phcomp.co.uk/Contact.html > #include > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Wed, Mar 2, 2022 at 8:34 AM Aaron Junker wrote: > Hi all > > As I see this there is strong agreement against war, but not for taking a > side on a conflict. > > So then why not showing a banner or something against war. No war or side > in particular just for humanity and peace. > > I think that's something everyone could agree with. > > Let me know what you all think. > I don't agree with that. I think war is horrible and should be avoided at all costs, but there are times it is justified. > > Best regards > Aaron > > From: Victor Bolshov > Sent: Wednesday, March 2, 2022 10:31:05 AM > To: internals@lists.php.net > Subject: [PHP-DEV] PHP Community to support Ukraine and help to stop > Russian agression > > Hello internals. > > In these dark days for humanity, we as people of civilization, people > of sanity, kind and caring people with children and families - we have > to speak up, loud and clear, in support for Ukraine. To stop Russian > aggression. > > I suggest to add Ukranian flag and a supportive anti-war disclaimer to > the header of php.net website. > > Why is this important? There are a lot of PHP developers in Russia. A > lot of them, sadly, have been brainwashed by Putin's propaganda. They > still must have a lot of respect to PHP authors and creators. Seeing > that these people, who have their respect, are against the war and for > the freedom of Ukraine, might have an impact. > > This is not the time to "stay away from politics", we are experiencing > an attack on humanity itself. Take example from > <https://junit.org/junit5/> and their clear statement. > > Say NO to war! > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
On Tue, Jan 25, 2022 at 5:11 PM Rowan Tommins
wrote:
> On 25/01/2022 19:44, Chase Peeler wrote:
> > If we start throwing exceptions, which can't be suppressed, it will make
> > this much more difficult to read since the constants.php will have to be
> > updated:
> >
> > if(!defined('dbserver')){
> >define('dbserver','productiondb.example.com');
> > }
> > if(!defined('otherconstant')){
> > define('otherconstants','foobar');
> > }
>
>
> A wrapper function for this use case is entirely trivial:
>
> function define_if_not_defined($name, $value) {
> if ( ! defined($name) ) {
> define($name, $value);
> }
> }
>
> Give it a short name like 'def', and your config file actually becomes
> shorter:
>
> def('dbserver', 'productiondb.example.com');
> def('otherconstants', 'foobar');
>
> "define" itself is just a function name, not a reserved word, so you
> could even declare the above as "define" in a namespace, then add "use
> function SomeNamespace\define;" and leave the rest of the file alone.
>
>
Bruce and Rowan - thanks for the suggestions. I like both of those and I
think they'll work in our situation. Appreciate you taking the time to
recommend some solutions instead of just telling me I'm doing it the wrong
way.
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
On Tue, Jan 25, 2022 at 3:08 PM Kamil Tekiela wrote: > A constant is a value that, unlike a variable, cannot be reassociated with > a different value. A properly written software should never redefine > constants. The possibility of redefining constants in PHP should be > considered a bug rather than a feature. > Constants are not good for configuration values that can be changed. A > proper data structure should be used instead. Constants should never have > to be redefined, either by the software itself, its tests or its > extensions. Constant values must remain the same under all circumstances > otherwise they are no longer constants. > > Regardless of whether it's a proper use of constants or not, it's something that was in place long before I started and not something we can easily change now. Also, I'm not suggesting that we allow constants to be redefined. My setup actually works because you can't redefine them. The idea is that the local configuration file is processed first. > +1 to remove it in PHP 9.0 > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
We have a main "constants.php" file that resides in git. The first line of
constants.php includes local_constants.php, which is kept out of git. The
idea is that we can "override" any of the constants on a per server basis.
constants.php:
@define('dbserver','productiondb.example.com');
local_constants.php
@define('dbserver','devdb.example.com');
If we start throwing exceptions, which can't be suppressed, it will make
this much more difficult to read since the constants.php will have to be
updated:
if(!defined('dbserver')){
define('dbserver','productiondb.example.com');
}
if(!defined('otherconstant')){
define('otherconstants','foobar');
}
On Sat, Jan 22, 2022 at 10:29 PM Mark Randall wrote:
> Internals,
>
> While cleaning up some PRs I was prompted to re-visit one I had
> outstanding about exception-throwing behaviour when redefining
> constants, this applies to functions like define and language syntax
> constructs such as const.
>
> There have been a few discussions in the past about the topic.
>
> Here is one from 2016 from Dmitry:
> https://wiki.php.net/rfc/constant_redefinition
>
> Discussion:
> https://externals.io/message/93885
>
> My own PR:
> https://github.com/php/php-src/pull/5265
>
> Since Dmitry's RFC was made in 2016, and my PR a while ago, attempted
> redeclaration was promoted from a notice to a warning, but I still think
> it's sensible to go one step further.
>
> There was mention on github that there was some resistence to promotion
> to exception in the past, but I think there is a strong possibility that
> the mood may be different many years later, with PHPs positive moves
> towards throwing on poorly defined or illogical behaviour.
>
> To gauge this, I'm throwing out a non-binding strawpoll to get the lay
> of the land before doing anything else with it. If there is general
> favour I'll fix up my patch and do a proper RFC.
>
> https://wiki.php.net/redefine_constants_exception_strawpoll
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] RFC: Trait expects interface
On Tue, Jan 18, 2022 at 3:55 PM Jordan LeDoux
wrote:
> On Tue, Jan 18, 2022 at 11:13 AM Rowan Tommins
> wrote:
>
> >
> > The difference with the "trait requires interface" proposal is that I
> > don't understand what advantage it gives the author of the trait. What
> > decisions can you make as a library developer because you've said "users
> > of this trait must implement the matching interface" as opposed to "...
> > can implement the matching interface"?
> >
> > It's possible there is some advantage I'm missing, but so far nobody
> > seems to have presented it.
> >
> >
> Well, the trait doesn't necessarily have to fulfill the entire interface,
> first of all. As you mentioned, this can be worked around using abstracts
> in the trait. However, what if you're dealing with return values within the
> trait?
>
> Suppose I have something like this:
>
> trait ArithmeticTrait {
> public function add(float $val): NumberInterface {
> // Do math
>
> return $this;
> }
>
> public function addmul(float $val): NumberInterface {
> $added = $this->add($val);
>
> if ($added->isPositive()) {
> // Do stuff
> }
>
> return $this;
> }
> }
>
This can still be handled with abstract methods
trait ArithmeticTrait {
public function add(float $val): NumberInterface {
$n = $this->getNumberInterface();
// Do math
return $n;
}
public function addmul(float $val): NumberInterface {
$n = $this->getNumberInterface();
$added = $this->add($val);
if ($added->isPositive()) {
// Do stuff
}
return $n;
}
abstract protected function getNumberInterface(): NumberInterface;
}
class Foo {
use ArithmeticTrait;
protected NumberInterface $n;
protected function getNumberInterface() : NumberInterface {
return $this->n;
}
}
>
> In this situation, the return value of the trait requires that $this
> implements the NumberInterface, however there is no way for the trait
> itself to enforce this.
>
> Jordan
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] RFC: Trait expects interface
On Thu, Jan 6, 2022 at 12:37 PM Alexandru Pătrănescu wrote: > On Thu, Jan 6, 2022 at 7:12 PM Rowan Tommins > wrote: > > > > > But some comments seem to be hinting at some *separate* advantage, to do > > with "correct usage" of the trait, which I haven't grasped. It's possible > > that the mention of static analysis relates to that in some way, and I'm > > just completely missing the point. > > > > Yes, traits are a language construct that has in general more negative > implications than positive so it's good to keep an eye on their usage. > One of the okish usages is to define some implementation for an interface > that classes can use. > Limiting that trait to be used only by classes implementing the interface > is seen as a restriction placed on the trait that would not allow it to be > used in other places when it might have a negative impact. > > And that's what I don't like about this. I'm totally OK with allowing developers to do things the "wrong" way. It might end up that it's the "right" way for their use-case. > Just as a note, on the composition vs inheritance line, I see traits > somewhere in the middle. > I'll always prefer to go for full composition, even if that means a bit > more boilerplate. The implementation can very well sit in a class and have > it as a dependency of the class that needs it. > > Alex > > but that wouldn't be any *easier* for the tool, and in fact would be extra logic for them to implement, so it seems an odd thing to bring up. I think most people see the tools as black boxes to make THEIR lives easier. They aren't concerned about whether it's added complexity to the tool itself. If PhpStorm allows me to reference $this->someMethodFromAnInterface() without defining someMethodFromAnInterface() as an abstract method in the trait because I include "expects ", then that means things are "simpler" for me as a developer. I don't really think this makes things that much simpler though. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] RFC: Trait expects interface
On Thu, Jan 6, 2022 at 11:20 AM Rowan Tommins wrote: > On 6 January 2022 15:21:28 GMT, Robert Korulczyk > wrote: > > It should also make it easier for SCA tools to understand > >the code since they no longer need to know the whole project to > understand that method from trait is implementation of method from > interface (which is > >really tricky right now since it depends on context - trait can at the > same implement and not implement the interface, because it depends on class > >where it is used). > > Your other points make sense, but I don't think this one does - there are > no implicit interfaces in PHP*, so all any tool cares about is: > > 1) Does the class declaration say that it implements an interface? > 2) Does it actually contain the methods needed to do so, through any > combination of direct implementation, inheritance, and trait usage? > > Knowing that a particular trait *could be* used to implement a particular > interface without further code doesn't really tell the tool anything - it > still has to resolve the list of methods on the class itself, and test > those against the "implements" clause. This is particularly true if the > class uses the "as" and "insteadOf" clauses when including the trait, which > nullify any promises the trait could make. > > > I think the advantage would come within the trait. If I say the trait expects an interface with two methods, then the tool can act as if the interfaces methods exist in the trait even if they aren't explicitly defined. As others have pointed out, though, you can get the same behavior from declaring the methods not implemented in the trait as abstract. > * other than "Stringable", whose purpose and implementation continue to > baffle me > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] RFC: Trait expects interface
On Wed, Jan 5, 2022 at 6:05 PM Larry Garfield
wrote:
> On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
>
> > First, I'm someone that mainly uses traits to implement the functionality
> > defined in an interface. I think that's one of the best uses for them.
> > However, I'm personally not a huge fan of overly restrictive things. For
> > instance, while there are definitely some use cases for them, I need a
> > REALLY good reason to justify making a property/method private instead of
> > protected, or making a class final.
>
> I am much the same.
>
> > As such, I think this would be better if it didn't throw a fatal error.
> > When you make it optional, however, I think you are left with something
> > that can be handled with an attribute just as well as a new keyword:
> > #[Expects('MyInterface')]
> > trait foo { }
> >
> > However, there might be value in generating a notice/warning, and I think
> > that would require a keyword, correct? (Not that up to speed on
> > annotations). Another option might be two support two new keywords:
> > requires and expects. The former would throw an error if the interface
> > isn't implemented while the latter will throw a warning/notice/nothing.
> >
> > Another option (and I haven't thought about this one enough to decide if
> I
> > like it) would be to have the expected interface automatically
> implemented
> > in the using class. This would allow the trait to be written under the
> > assumption it has access to the methods defined in the interface, and
> will
> > then throw an error if any of the methods are not implemented in the
> using
> > class:
> >
> > interface foo {
> > function a();
> > function b();
> > }
> >
> > trait bar expects foo {
> >function c(){
> >return $this->a() + $this->b();
> >}
> > }
> >
> > class baz {
> > use foo;
> > }
> >
> > The above would throw an error since a() and b() are never implemented
> and
> > baz is implementing the foo interface. You can currently get the same
> > behavior if you define a() and b() as abstract in the trait. However,
> this
> > doesn't give you the added benefit of utilizing the interface
> automatically
> > within the type system. The more I think about it, the less I like this
> > idea, since it doesn't require that much additional work to make the code
> > clearer by explicitly implementing the interface on the class if you want
> > it implemented. However, I'll go ahead and leave it here because it might
> > help generate some other ideas.
>
> I... still don't see any use in this annotation.
>
> Stepping back and ignoring the syntax for a moment, there's two different
> things here:
>
> 1. "This trait expects to be used in a class that has these other methods
> on it".
> 2. "This trait mostly/fully fulfills interface X, because it has methods
> a, b, and c."
>
> For point 1, we already have that. It's called abstract methods in
> traits. This is a solved problem that requires no further resolution. At
> best it would be a shorthand to copying a few methods from an interface
> into the trait and sticking "abstract" in front of them. I really don't
> see a need for that.
>
>
Agreed. It would also allow IDEs and what not to determine the trait has
access to the interface methods that you didn't explicitly define as
abstract, but I still agree that it would just be shorthand that isn't
really needed.
> For point 2, that's mainly useful as a way to signal to other developers
> "hey, this trait has all but one method of the LoggerInterface, that's how
> you'd use it", and to signal static analyzers and refactoring tools the
> same thing so that they can be auto-updated if you tweak the interface. I
> can see a use for point 2, and it would make my life a bit easier, but it's
> overall not high priority.
>
>
I also agree.
I was focusing more on fleshing out the idea in general. I think the idea
is interesting enough that it's worth discussing even if it doesn't seem
like it's worth pursuing in its current form.
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
On Wed, Jan 5, 2022 at 3:24 PM Andreas Hennings wrote:
> On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux
> wrote:
> >
> >
> >
> > On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings
> wrote:
> >>
> >> Hello Jordan,
> >> do you have any thoughts about these symmetric/left/right modifiers,
> >> to get rid of the $operandPos parameter?
> >>
> >> To me, the parameter could be the kind of thing where in hindsight we
> >> ask "why?".
> >>
> >> Also, can we drop the "public" modifier, if we do a new version of the
> RFC?
> >>
> >> Cheers
> >> Andreas
> >
> >
> > It's a totally different design concept (symmetric/left/right) and I've
> been going over the design implications before I responded. For instance,
> wouldn't this be a special case of method overloading? You're overloading
> according to a modifier, not the typing, but there is that to contend with.
> If someone defined `symmetric operator +` and `left operator +` which would
> be used? (My feeling is left as its more specific.)
>
> You would not be allowed to provide both on the same class.
>
> A class can provide either no operator, or the left operator, or the
> right operator, or both.
> A "symmetric" operator is a shortcut to providing both left and right,
> but using the same implementation.
> A class with a "symmetric" operator cannot also have a "left" or
> "right" version of the same operator - this would be the same as two
> methods with the same name.
> However, if the parent class has a "symmetric" operator, you _can_
> override the "left" and/or "right" version in the subclass. In that
> case, if the subclass provides "left", then the parent "symmetric"
> implementation would only be used for the "right" direction.
>
> I am writing "right" and "left" here, but perhaps "normal" and
> "inverted" would be less ambiguous.
> Also, perhaps instead of "symmetric" we could write "left right".
>
> Perhaps this code will clarify:
>
> class C {
> symmetric operator * (int $other) {..}
> # left operator * (int $other) {..} // -> Error, already defined.
> left operator - (int $other) {..}
> right operator - (int $other) {..}
> left operator / (float $other) {..}
> left operator % (D $other) {..}
> }
>
> class D {
> right operator % (C $other) {..}
> }
>
> (new C()) * 5; // -> symmetric operator *
> 5 * (new C()); // -> symmetric operator *
> (new C()) - 5; // -> left operator -
> 5 - (new C()); // -> right operator -
> (new C()) / 5; // -> left operator /
> 5 / (new C()); // -> Error, no operator provided.
>
> (new C()) % (new D()); // -> left operator % provided by C.
> (new D()) % (new C()); // -> Error, not supported.
>
> This means, the "right operator" will only ever be called if the left
> side does not provide a "left operator".
>
> Basically this is not so different from your RFC.
> Just instead of having to do a "if ($operandPos ===
> OperandPosition::LeftSide) {..}" inside an implementation, we are
> providing two separate implementations.
>
>
> > How would they be stored within the zend_class_entry? Since they would
> technically have the same name, something would need to happen for them to
> not be in the function table.
>
> The right and left version would need to be distinguished somehow
> internally.
> I would say "left" is the default, and "right" has a modifier to its name.
> Perhaps for symmetric operators, we could store two distinct entries
> internally, if that makes things easier.
>
>
If nothing else symmetric could be handled by having the compiler replace
it with left/right version that executes the same code
> >
> > The public modifier is not required (as stated in the RFC), you can just
> add it if you want. Are you asking for `public operator` to produce a
> compile error?
>
> That would be the idea.
> Perhaps others will disagree.
> Allowing the "public" introduces a meaningless choice that people can
> argue about in their code style, and have pointless git commits where
> they add or remove the modifier based on preference.
> Of course the same could be said about "public" in interface methods.
>
>
I personally don't like it when I don't have a consistent look to my code.
One of the things that bother me is code like:
function foo(){}
protected function bar(){}
function baz(){}
I want everything to have a visibility indicator for visual consistency.
That's why I always use public in my interface methods as well. So, even
though it won't cause confusion if omitted for an operator, since it can
only be public, I still think it should be allowed.
> -- Andreas
>
> >
> > Jordan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] RFC: Trait expects interface
On Wed, Jan 5, 2022 at 2:17 PM David Gebler wrote:
> On Tue, Jan 4, 2022 at 10:35 PM Kirill Nesmeyanov wrote:
>
> > How relevant do you think this idea/proposal is? And what possible
> > problems or solutions will this entail in the future?
> >
>
> I'm not convinced there's a reasonable need for it. The very nature of
> finding yourself in a situation where you want any class using a trait to
> also require other things outside the trait kind of suggests you really
> want to be using interfaces or abstract classes anyway.
>
> There is a similar concept for what I think you're trying to achieve in
> Java, though, which could also be useful in PHP if it was feasible within
> the engine - the ability to provide a default method implementation on
> interfaces themselves.
>
> Short of that, we can already effectively get there with the tools we have;
> an abstract class can use a trait and define abstract or concrete methods,
> and in doing so can implement one or more interfaces. Obviously traits can
> also declare abstract methods but I assume it's the identity/type aspect of
> an interface you want here which isn't satisfied by that approach.
>
> Also worth noting, although I can't say I'm familiar with the mechanics of
> traits in PHP's implementation, my understanding has always been that
> they're effectively compiler-level copy and paste in to a class so I'm not
> sure what interfaces are implemented by the class (or conversely allowing a
> trait to implement an interface) would be readily achievable.
>
> That's my two cents, good luck with whatever you're trying to do anyway.
>
> - David
>
>
> > --
> > Kirill Nesmeyanov
>
First, I'm someone that mainly uses traits to implement the functionality
defined in an interface. I think that's one of the best uses for them.
However, I'm personally not a huge fan of overly restrictive things. For
instance, while there are definitely some use cases for them, I need a
REALLY good reason to justify making a property/method private instead of
protected, or making a class final.
As such, I think this would be better if it didn't throw a fatal error.
When you make it optional, however, I think you are left with something
that can be handled with an attribute just as well as a new keyword:
#[Expects('MyInterface')]
trait foo { }
However, there might be value in generating a notice/warning, and I think
that would require a keyword, correct? (Not that up to speed on
annotations). Another option might be two support two new keywords:
requires and expects. The former would throw an error if the interface
isn't implemented while the latter will throw a warning/notice/nothing.
Another option (and I haven't thought about this one enough to decide if I
like it) would be to have the expected interface automatically implemented
in the using class. This would allow the trait to be written under the
assumption it has access to the methods defined in the interface, and will
then throw an error if any of the methods are not implemented in the using
class:
interface foo {
function a();
function b();
}
trait bar expects foo {
function c(){
return $this->a() + $this->b();
}
}
class baz {
use foo;
}
The above would throw an error since a() and b() are never implemented and
baz is implementing the foo interface. You can currently get the same
behavior if you define a() and b() as abstract in the trait. However, this
doesn't give you the added benefit of utilizing the interface automatically
within the type system. The more I think about it, the less I like this
idea, since it doesn't require that much additional work to make the code
clearer by explicitly implementing the interface on the class if you want
it implemented. However, I'll go ahead and leave it here because it might
help generate some other ideas.
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key
On Mon, Jan 3, 2022 at 10:48 AM Rowan Tommins wrote: > On 3 January 2022 15:41:48 GMT, Chase Peeler > wrote: > >But "001" casted to 1 will then get casted back to "1" not "001". > > "001" would not be cast to an integer in this context: > https://3v4l.org/gGFHJ > > My mistake, I thought it did get casted. Still, I think you add a lot of complexity because you'll need to keep track of whether or not a key was a string or not. There is no guarantee that all numeric keys were originally a string: [ "1" => "foo", 2 => "bar"] And, for the record, I am not in favor of the original proposal either. I think it's way too big of a BC break like others have said. > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key
On Sun, Jan 2, 2022 at 7:05 AM Rowan Tommins
wrote:
> On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov wrote:
> >
> >I just gave an example of what at the moment can cause an exception in
> any application that is based on the PSR. It is enough to send the header
> "0: Farewell to the server". In some cases (for example, as is the case
> with RoadRunner) - this can cause a physical stop and restart of the server.
>
> Any library where a crafted HTTP request can cause a server shutdown has a
> bug which needs addressing right now - possibly more than one, actually, as
> it implies error handling is leaking across request boundaries. A change to
> the language applied in the next major version would fix this some time
> around 2025, once people start adopting it. A workaround in the library
> itself can be applied within weeks.
>
> I already gave a simple solution that such libraries can apply right now,
> with very little chance of negative impact: sanitise headers more
> aggressively than the HTTP standard requires, as Apache httpd does, in this
> case discarding any header containing only digits. This is likely to be
> about three lines of code inside a loop preprocessing raw headers:
>
> if ( ctype_digit($rawHeaderName) ) {
> trigger_error("Numeric HTTP header '$rawHeaderName' has been
> discarded.", E_USER_WARNING);
> continue;
> }
>
> If I was the maintainer of such a library, I might consider even stricter
> validation, considering what seems like an accidentally broad definition in
> the HTTP spec, and the possibility of an application receiving even more
> exotic characters if processing raw TCP traffic.
>
>
> The idea of an array_keys variant or option that forces everything back to
> string seems like it might be useful (and easy to polyfill for old
> versions). Changing such a fundamental language behaviour in the hope that
> it will fix more code than it breaks is just not worth it.
>
>
But "001" casted to 1 will then get casted back to "1" not "001".
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown wrote: > On Fri, 12 Nov 2021 at 08:08, Nikita Popov wrote: > > > Hi internals, > > > > I've opened the vote on > > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close > > 2021-11-26. > > > > Regards, > > Nikita > > > > There are two things developers think about when releasing code: > > 1. does it work for me > 2. does it work for everyone else > > With its support for runtime type hints and other similar checks, PHP does > a reasonably good job of aligning those two — what works for me _generally_ > works for everyone else, too. > > Using dynamic properties is one of the areas where "works for me" and > "works for everyone else" can diverge. Some people use static analysis to > keep track of those divergences, but if PHP _can_ warn people they're doing > a probably-dumb thing, I think it should. > > Warning someone is very different than not allowing it > I encourage people to vote "yes" on this, if you want PHP to be better at > preventing people from shooting themselves in the foot. What if I want a language where people can shoot themselves in the foot because the flexibility it offers is what makes it great > I know there are > valid uses for this, but it's nevertheless a surprising feature, and not > one that delights many PHP developers. Why is this surprising? It's been available since classes were introduced to PHP. > Making it attribute-only from 9.0 > onwards seems incredibly sensible. > > Best wishes, > > Matt > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
On Mon, Nov 15, 2021 at 3:11 PM Deleu wrote: > By design my REST API utilizes dynamic properties. I've always found it to >> be a feature of PHP, not a bug. >> >> -- >> Chase Peeler >> chasepee...@gmail.com >> > > I am in the unfortunate position of inheriting a system with such REST API > design. I can never build new REST APIs to replace the old ones because > nobody can ever know how many combinations of possible input parameters > there are. > > Our inputs and outputs are both well defined. I've built a framework around our entities that convert them into API payloads - attributes (symfony, but eventually we might update it to use native attributes) define what fields are visible based on user and whether it's the short (e.g. part of a collection) or full version. The thing is that occasionally we'll have a payload to return that requires additional attributes. Dynamic properties allow us to just tack that on to the existing entity without having to define it as a property on the entity (outside of the one use case the property isn't needed and it definitely doesn't correspond to a database column). > -- > Marco Aurélio Deleu > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
On Mon, Nov 15, 2021 at 3:02 PM James Gilliland wrote: > On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans wrote: > > > Dear Internals, > > > > On Wed, 10 Nov 2021, Nikita Popov wrote: > > > > > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov > > wrote: > > > > > > > This RFC takes the more direct route of deprecating this > > > > functionality entirely. I expect that this will have relatively > > > > little impact on modern code (e.g. in Symfony I could fix the vast > > > > majority of deprecation warnings with a three-line diff), but may > > > > have a big impact on legacy code that doesn't declare properties at > > > > all. > > > > > > > > > > I plan to open voting on this RFC soon. Most of the feedback was > > > positive, apart from the initial choice of opt-int mechanism, and that > > > part should be addressed by the switch to the > > > #[AllowDynamicProperties] attribute. > > > > The voting is now open, but I think one thing was not taken into account > > here, the many small changes that push work to maintainers of Open > > Source library and CI related tools. > > > > In the last few years, the release cadence of PHP has increased, which > > is great for new features. It however has not been helpful to introduce > > many small deprecations and BC breaks in every single release. > > > > This invariably is making maintainers of Open Source anxious, and > > frustrated as so much work is need to keep things up to date. I know > > they are *deprecations*, and applications can turn these off, but that's > > not the case for maintainers of libraries. > > > > Before we introduce many more of this into PHP 8.2, I think it would be > > wise to figure out a way how to: > > > > - improve the langauge with new features > > - keep maintenance cost for open source library and CI tools much lower > > - come up with a set of guidelines for when it is necessary to introduce > > BC breaks and deprecations. > > > > I am all for improving the language and making it more feature rich, but > > we have not spend enough time considering the impacts to the full > > ecosystem. > > > > I have therefore voted "no" on this RFC, and I hope you will too. > > > > cheers, > > Derick > > > > I appreciate that Derick. I know there have been some pretty big efforts > required for some recent php updates in Drupal. And I've mentioned in a > couple threads on Twitter but Drupal requires a pretty heavy change to > support this. It adds properties to classes _outside_ its codebase which > means none of the mitigations in the RFC apply. It was on my radar when the > vote popped up because the system in question has long been known to be > less than ideal but "php wouldn't ever remove this ancient feature right?" > and every other option is just a ton more complicated. I've talked with > some maintainers and it looks like we're going to deal with the cost of > converting the system but if this dirty hack hadn't been on our radar it > could have really hurt. Like maybe not getting the fix in place before the > next major release in time for backwards compatibility commitments bad. > > So I worry what sort of earthquake this might trigger through libraries. > Like, I'm pretty sure the OpenApiGenerator templates used dynamic > properties for some things so how many little internal libraries are going > to have to be regenerated? What other lightly maintained library are people > going to be stuck waiting to update because someone's CI didn't catch the > deprecation? > By design my REST API utilizes dynamic properties. I've always found it to be a feature of PHP, not a bug. > > I think this sort of change is probably for the better, but I worry about > how disruptive this could end up being. > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield wrote: > On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote: > > On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov > wrote: > > > >> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey wrote: > >> > >>> > On Nov 12, 2021, at 10:10, Derick Rethans wrote: > >>> > > >>> > On 12 November 2021 13:07:42 GMT, Nikita Popov > > >>> wrote: > >>> >> Hi internals, > >>> >> > >>> >> I've opened the vote on > >>> >> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will > >>> close > >>> >> 2021-11-26. > >>> > > >>> > I've voted no on this one. Not because I don't like the idea, but > >>> because I think the timeline for deprecation and removal is way too > fast. > >>> > > >>> > This is IMO not something important enough to cause a fairly large BC > >>> break for, and it should wait until the last in the 8.x series before > we > >>> deprecate it. > >>> > > >>> > cheers > >>> > Derick > >>> > >>> > >>> I’ve voted no for the same reason. > >>> > >>> I like this change, but the deprecation in 8.2 seems too disruptive. > I’d > >>> rather promote our intent to deprecate this with a statement in the > >>> manual that says something like, “This feature will be deprecated in > >>> PHP 8.3 and removed in 9.0.” > >> > >> > >> FWIW I think we should always deprecate things as soon as possible, to > >> give people the maximum amount of awareness and time to address the > issue > >> before the actual removal occurs. Most people will not be aware they > need > >> to take action if it's just a note in the manual. For that reason, I > find > >> it generally preferable to deprecate something closer to PHP 8.0 than to > >> 8.4, which would be directly before a major version with limited time to > >> act. Now, we don't usually tend to optimize for "time of deprecation" > >> because that requires planning deprecations many years in advance, but > if > >> the choice existed I'd always go for deprecating early in the major > release > >> cycle, rather than late. > >> > > > > Another thing I want to add here is that in this instance, I think that > the > > deprecation warning is really helpful for updating your code. It tells > you > > exactly which property on which class is being created dynamically, so > you > > can quickly go through these and add missing property declarations or > > #[AllowDynamicProperties] attributes. Without the deprecation warning in > > place, you need a static analyzer to find problematic cases. And of > course, > > that only works well if you already have a fully typed code base that is > > reasonably clean under static analysis. At the same time, this change is > > most likely to affect projects where this is not the case. If you are > > already using a static analyzer, you probably don't use dynamic > properties > > anyway, as these things tend to be incompatible. > > > > Regards, > > Nikita > > Also a reminder that deprecations are not errors; PHPUnit very recently > changed to not complain about deprecations by default. And anyone running > with deprecations on in production is doing it wrong and will get bitten > whenever the deprecation is enabled. > > I have to agree with Nikita here. Give people as much deprecation time as > possible; if people are misunderstanding deprecations and abusing them, > that's... a different problem that cannot be solved by not issuing > deprecations. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I don't think this should be deprecated or removed at all. However, I agree that if it is going to be removed, the more time/versions that exists between deprecation and removal, the better. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Deprecate dynamic properties
On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins wrote: > On 25/08/2021 13:45, Nikita Popov wrote: > > > We obviously need to keep support for dynamic properties on stdClass, > > and if we do so, I would expect that to apply to subclasses as well. > > Does that actually follow, though? Right now, there is no advantage to > extending stdClass, so no reason to expect existing code to do so, and > no reason for people doing so to expect it to affect behaviour. > > > > Second, I consider "extends stdClass" to be something of a last-ditch > > option. If you encounter a dynamic property deprecation warning, you > > should generally resolve it in some other way, and only fall back to > > "extends stdClass" as the final option. > > > That's a reasonable argument in terms of the multiple inheritance case. > > My concern about the name remains though: people already do get confused > by the name "stdClass", because it's not in any way "standard", and > tells you nothing about what it does. > > Reading "class Foo extends stdClass" gives the reader no clues what > magic behaviour is being inherited; "class Foo extends DynamicObject" > would be much more clear. Similarly, "$foo = new DynamicObject; > $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Please don't do this. Call it bad coding practices or not, but this was something I've considered a feature of PHP and have actually built things around it. It's not something that can be easily refactored since it was part of the design. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Request for karma to vote on RFCs
On Tue, Jul 20, 2021 at 2:22 AM Andreas Heigl wrote: > Hey All > > Am 19.07.21 um 17:02 schrieb Andreas Heigl: > > Hey All > > > > Am 19.07.21 um 16:34 schrieb Levi Morrison via internals: > >> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov > wrote: > >>> > >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm > > >>> wrote: > >>> > >>>> Hey. > >>>> I would like to get karma to be able to vote on RFCs. I understand > that > >>>> voting karma isn’t usually given out to people who write their first > >>>> mailing list entry. > >>>> > >>>> But I do believe I qualify as “Lead developers of PHP based projects > >>>> (frameworks, cms, tools, etc.)” > >>> > >>> Hey Tobias, > >>> > >>> My response here is basically the same as the last time the topic came > up: > >>> https://externals.io/message/110936#110937 Voting is just the very > last > >>> step of the RFC process, at which point the proposal can no longer be > >>> influenced. If you have feedback about a proposal based on your > extensive > >>> experience in PHP's open source ecosystem, then the discussion phase > is the > >>> time to provide it, while it can still influence the proposal, as well > as > >>> other people's view of the proposal. > >> > >> I second this. > >> > >>> At least in my personal opinion, I think it's important that people > granted > >>> voting rights as community representatives have at least some > historical > >>> involvement in RFC discussions. > >> > >> I agree with this, but have no specific objection to granting Tobias > >> voting karma, as this is underspecified; how long should they > >> participate? What kinds of involvement are appropriate? Being > >> underspecified is not really their fault, and I don't feel like it > >> would be an abuse to grant them voting karma, but do think it would be > >> an abuse to deny them voting karma indefinitely because "we" don't get > >> around to specifying it. It should be less of a decision on a > >> case-by-case basis and more of a checklist. > >> > > > > Sounds like we need an RFC to make it clearer how voting karma for the > > RFC process will be granted in the future. > > I have created a draft for an RFC to implement future rules for granting > voting karma. > > If you want to contribute to that, feel free to open a PR against it[1]. > > To be able to make the future karma grants more trnasparent this needs > input from everyone: Opponoents as well as proponents! > > I'm looking forward to a fruitful conversation and to a great RFC that > can move us to more transparency. > > Cheers > > Andreas > > [1] > > https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md > Here is the problem (and I don't know if there is a good solution to this) - the requirements are still subjective. How much interaction is required with the PHP sourcecode ecosystem? What is considered a "consistent effort?" How much interaction with the "main discussions medium" is needed? If we are going to change how karma is given, I think we really need to determine solid, objective criteria. I honestly don't know what this looks like. Everything I can think of has issues. For example, if we decided to allow a path for non-core contributors to gain karma, what would we base that on? Anything around the number of commits, projects worked on, etc., can be easily gamed. Allowing those that already have voting karma the final decision over who gets voting karma is also problematic. Like Tobias, I have gotten the "elitist" feeling at times from the group. Finally, I think the idea of "approvals outweighing objections" is not good. While it definitely is a purely objective measurement, it shows why I think it is so hard (if not impossible) to find good measurements that are purely objective. What if we get one objection that rightly says "This person shows that they have no knowledge of how PHP actually works" compared to two approvals saying "I like this person, so I'm OK with it" -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Could we drop the bottom-posting rule?
On Tue, May 11, 2021 at 11:48 AM Michael Morris wrote: > If this list has ever had a "bike shed" issue, this would be it. > > https://en.wikipedia.org/wiki/Law_of_triviality > > > I agree, but it's within its own thread and not hijacking other ones, so no harm in discussing it. > > On Tue, May 11, 2021 at 10:01 AM Mel Dafert wrote: > > > >> This plaintext reply sent via Gmail web client. I don't know what Mel > is > > >> talking about either. > > >> > > >> > > >Gmail's web client is what I normally use, and have never had an issue > > with > > >it. > > > > Sorry for being unclear - I meant the Gmail android app. > > > > If the app does have an option for plaintext emails, I am not able to > find > > it. > > If it does, that might also be useful to document somewhere, so people > > like me can actually use it :) > > > > Even then, I also don't think it offers an option to bottom-post by > > default - which K-9 and Thunderbird do. > > (No idea about the Gmail web client - I don't use it regularly.) > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Body-less __construct
On Tue, May 11, 2021 at 10:48 AM Matīss Treinis wrote: > Hi Sara, > > > While it's certainly silly/pointless to have a nil constructor when > there are non-promoted args present, I think that deliberately making > that mode special (read: inconsistent) is the wrong way to go. > > Sorry, but I don't follow - so you would prefer that this: > > public function __construct(); > > be valid syntax as well, considering within the scope of the proposed? > Am I reading this right? > > Yes. It might be silly and pointless, but, it doesn't have any negative side effects, so why not? > - Matīss > > On Tue, May 11, 2021 at 09:33, Sara Golemon wrote: > > On Tue, May 11, 2021 at 5:18 AM Matīss Treinis > <mailto:mrtrei...@gmail.com>> wrote: > > > Yes, just to clarify the scope of my initial proposal, this should > > only > > > ever apply to promoted constructors that have 1 or more promoted > > > parameters, and no not-promoted parameters. > > > > > > > Hard disagree. While it's certainly silly/pointless to have a nil > > constructor when there are non-promoted args present, I think that > > deliberately making that mode special (read: inconsistent) is the > > wrong way to go. > > > > > These would NOT be considered valid: > > > public function __construct(); > > > > > > > For example, Niki's reply showed a place where that mode is perfectly > > reasonable (singleton finals). If you must have this syntactic > > sugar, then please make it consistent. > > > > > as well as anything not related to __construct. > > > > > > > I'd be willing to go along with inconsistency since once you allow > > syntax you can't unallow it without pain. So while I don't love the > > tack, I'll follow it if we do this feature. (which IMO we shouldn't). > > > > > > > > On Tue, May 11, 2021 at 8:59 AM Matīss Treinis > <mailto:mrtrei...@gmail.com>> wrote: > > > If there are no super strong arguments on why this should not > > happen or go > > > to RFC, I will draft a RFC and from there, the usual process > > applies. > > > > > > > I think you've heard a number of strong arguments why it should not > > happen, but I also think this deserves its chance to be fleshed out > > and voted on, so by all means, do work the RFC. > > > > -Sara > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Could we drop the bottom-posting rule?
On Tue, May 11, 2021 at 10:36 AM Sara Golemon wrote: > On Tue, May 11, 2021 at 9:21 AM Chase Peeler > wrote: > > On Tue, May 11, 2021 at 2:34 AM Mel Dafert wrote: > > > (Gmail certainly can't, it can't even send non-HTML mails, and even > with > > > K-9 I have to remember doing it.) > > > > > I’m sending this from gmail on my phone, so not sure what you are talking > > about. > > > > This plaintext reply sent via Gmail web client. I don't know what Mel is > talking about either. > > Gmail's web client is what I normally use, and have never had an issue with it. For work I use outlook and I often do in-line replies as well. That's usually combined with a top post reply saying "see inline" since top posting is the convention everyone uses at work. I can also tell you it's much more difficult to go back through a long thread of emails when you have to read everything from the bottom up. I also wanted to address a few comments people have made around being told to top post. I've seen my fair share of snark on this board. Not once have I ever seen anyone make a big deal out of someone top posting. I don't even recall a time when someone replied JUST to tell them not to top post. I've only seen it presented as a gentle reminder as part of a reply on the actual topic. > -Sara > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Body-less __construct
On Tue, May 11, 2021 at 10:34 AM Sara Golemon wrote: > On Tue, May 11, 2021 at 5:18 AM Matīss Treinis > wrote: > > Yes, just to clarify the scope of my initial proposal, this should only > > ever apply to promoted constructors that have 1 or more promoted > > parameters, and no not-promoted parameters. > > > > Hard disagree. While it's certainly silly/pointless to have a nil > constructor when there are non-promoted args present, I think that > deliberately making that mode special (read: inconsistent) is the wrong way > to go. > > > These would NOT be considered valid: > > public function __construct(); > > > > For example, Niki's reply showed a place where that mode is perfectly > reasonable (singleton finals). If you must have this syntactic sugar, then > please make it consistent. > > > as well as anything not related to __construct. > > > > I'd be willing to go along with inconsistency since once you allow syntax > you can't unallow it without pain. So while I don't love the tack, I'll > follow it if we do this feature. (which IMO we shouldn't). > > > I agree. I think making things inconsistent between constructors and other methods is something that can be lived with - there are already other things special about constructors that don't apply to other methods - but we should at least allow consistency among constructors and allow the trailing semicolon in all cases. > > On Tue, May 11, 2021 at 8:59 AM Matīss Treinis > wrote: > > If there are no super strong arguments on why this should not happen or > go > > to RFC, I will draft a RFC and from there, the usual process applies. > > > > I think you've heard a number of strong arguments why it should not happen, > but I also think this deserves its chance to be fleshed out and voted on, > so by all means, do work the RFC. > > -Sara > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Could we drop the bottom-posting rule?
On Tue, May 11, 2021 at 2:34 AM Mel Dafert wrote: > On 10 May 2021 23:57:51 CEST, Christian Schneider > wrote: > >No. > >Outlook is not modern. > > While I agree with this (and I also agree with keeping bottom-posting), I > feel like we could make this easier > for new contributors by giving some examples of which clients to use and > how to configure them. > What clients are people using that make this convenient? > On desktop, I assume Thunderbird can do this, and my web client (zimbra) > also can. > On mobile, I've settled with the beta version of K-9 - I don't know of any > other client that can do this. > (Gmail certainly can't, it can't even send non-HTML mails, and even with > K-9 I have to remember doing it.) I’m sending this from gmail on my phone, so not sure what you are talking about. > And please don't say that mobile clients don't matter - if we want to make > it easy for new people to join, > we should also make sure we support using mobile. > > Regards, > Mel > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Body-less __construct
On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier
wrote:
> On Mon, May 10, 2021 at 10:29 AM Matīss Treinis
> wrote:
>
> > Hi everyone,
> >
> > Since constructor property promotion is now implemented, and it looks
> > like it could become a widely used feature, I am proposing a small,
> > cosmetic change in syntax for constructors in concrete classes to do
> > away with empty constructor body.
> >
> > Here's an example of how this would work:
> >
> > > namespace App;
> >
> > class Foo {
> > public function __construct(
> > private Bar $bar,
> > private Baz $baz
> > );
> > }
> >
> > Some notes to this:
> >
> > - Since this is similar to already existing syntax for body-less
> > methods, parser should not be affected that much. I hope. I really have
> > no idea.
> > - Syntax would be optional - meaning, you can as well continue using
> > empty body, just that in this case the body would be implied empty.
> >
> > Thoughts?
> > Regards,
> > - Matīss
> >
> >
> Hi,
>
> To me `;` means not "empty body" (that's `{}`) but really "no definition,
> only declaration" (or "no body, only signature", and also "no code
> executed"), i.e. an *abstract* method (either explicitly declared so in a
> class, or implicitly in an interface).
>
> Granted, property promotion is already special (cannot be used in an
> abstract constructor), but it can also be mixed with non-promoted
> parameters and body, so I feat that your proposed alternative syntax would
> bring more confusion than convenience :s
>
> Regards,
>
> --
> Guilliam Xavier
>
I'm ambivalent about this proposal, but figured I'd throw out one advantage
to ; over {}. In my opinion, ending with a semicolon is a very clear way of
saying there is no body to the method, while having {} could indicate that
implementation of the body was intended but never actually done. I know
that when I'm writing new classes I often will set up the method signature
but leave the method body empty while I finish the code that utilizes that
method. I don't know if that is justification for the proposal, but it is
one reason why ; might be preferred over {}.
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Sealed Classes
On Tue, Apr 27, 2021 at 7:00 PM Larry Garfield
wrote:
> On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote:
> > On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield
> > wrote:
> >
> > The two options to prevent such errors are:
> > >
> > > 1. Sealed classes.
> > > 2. Extend Enums into ADTs.
> > >
> >
> > Unless I've misunderstood your example, there is a third option which
> quite
> > possibly prevents the error in a nicer, easier to reason about, more
> > flexible pattern.
> >
> > class Perhaps extends Maybe implements OperatesOnTheValueInterface { ...
> }
>
> If we were dealing with a service object in classic OOP (viz, OOP based on
> classes), then yes, turning the function into a method and using
> polymorphism would be the correct answer, rather than RTTI.
>
> However! Classic OOP design patterns are not all that PHP supports, and
> that's a good thing. The "class" construct, for better or worse, is the
> syntax for logic objects, value objects, data objects, and control flow
> objects (such as Maybe, Either, etc.), plus assorted other patterns that
> are not part of the classic OOP canon. But they're still good and useful
> patterns, and often a better model than classic OOP "polymorph all the
> things" approaches.
>
> If we were designing PHP from scratch today, I'd argue for having separate
> language constructs for funcy-syntax-closures (which is what service
> objects are), product types (structs, value objects, all the same thing),
> and control flow types. Many newer languages do differentiate those
> better. That's not where we are, though, so we're stuck with class being
> the uber-syntax for anything even slightly interesting from a type
> perspective. So be it, but it does lead to ample confusion about which use
> case you're talking about, especially when not everyone is familiar with
> all of the different, distinct use cases.
>
> See also: This thread. :-)
>
> Sealed classes are... not really useful at all for service object use
> cases. They are useful for product type and control flow type use cases.
>
>
And I think that is where our approaches differ. You feel that since sealed
classes are useful for at least one of the ways classes can be used in PHP,
then we should make them available even if that means they end up getting
used with the ways that they don't make sense. My feeling is that we
shouldn't introduce something that would cause restrictions where they
don't make sense just so we can have them where they do.
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Sealed Classes
On Tue, Apr 27, 2021 at 2:57 PM Olle Härstedt
wrote:
> 2021-04-27 20:17 GMT+02:00, Chase Peeler :
> > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals <
> > internals@lists.php.net> wrote:
> >
> >> I think the conversation on final classes being "bad" has gone on long
> >> enough. You don't like final, and you don't want to see more features
> >> like it being added, such as sealed. Point taken. Now please stop
> >> dominating the discussion, thank you.
> >>
> >>
> > I think the legitimacy of final/sealed classes goes to the heart of this
> > RFC. As long as people are going to discuss it and bring up counter
> points,
> > then I think asking someone to stop defending their view is a bit out of
> > line.
> >
> > That being said, David has never said he is against developers being able
> > to annotate their classes as being final or sealed. He is just against
> the
> > engine enforcing such requirements. On this I agree. I understand that
> > other languages support this concept - and frankly, I don't care. The
> > flexibility that PHP offers has always been one of its greatest strengths
> > and this just further erodes that.
> >
> >
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: https://www.php.net/unsub.php
> >>
> >>
> >
> > --
> > Chase Peeler
> > chasepee...@gmail.com
> >
>
> Sometimes it's helpful to apply a risk perspective the shed some light
> under hidden assumptions of different arguments. For example, what's
> the probability and impact of an event that would limit a coder when a
> library is using a sealed class? And the other way around, what's the
> probability and impact of an event that would decrease code quality
> when a sealed class is *not* used (like being able to subclass
> Maybe/Option even when it "shouldn't" be possible)?
>
>
As someone mentioned above, maybe they want to just add some logging
capabilities to maybe.
class MyMaybe extends Maybe {
protected $logger;
public function setLogger($logger){ $this->logger = $logger; }
public function value(){
if(null !== $this->logger){ $this->logger->log("getting value"); }
return parent::value();
}
}
> If the probability of such an event is high, but the impact to overall
> code quality is low, the risk is also considered low. (Example: Just
> create your own Maybe class. Of course harder with more elaborate
> classes, you don't want to copy-paste an entire library. And the other
> way, extending Maybe is a very local thing to do and doesn't hurt the
> library itself.)
>
>
Copy/pasting Maybe into my own MyMaybe class isn't going to be a valid
option if I encounter something like
function(Maybe $maybe){...}
If I can subclass Maybe, then it will work. If MyMaybe is a totally
different class, though, it won't.
> When both probability and impact are uncertain, it will make it harder
> to create consensus, and will make arguments more emotional or
> heuristic. When risk is low and the benefit high (and clear),
> consensus is easy.
>
> Olle
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Sealed Classes
On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals < internals@lists.php.net> wrote: > I think the conversation on final classes being "bad" has gone on long > enough. You don't like final, and you don't want to see more features > like it being added, such as sealed. Point taken. Now please stop > dominating the discussion, thank you. > > I think the legitimacy of final/sealed classes goes to the heart of this RFC. As long as people are going to discuss it and bring up counter points, then I think asking someone to stop defending their view is a bit out of line. That being said, David has never said he is against developers being able to annotate their classes as being final or sealed. He is just against the engine enforcing such requirements. On this I agree. I understand that other languages support this concept - and frankly, I don't care. The flexibility that PHP offers has always been one of its greatest strengths and this just further erodes that. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Sealed Classes
ed class Maybe permits Some, None {
> > > ...
> > > > }
> > > >
> > > > final class None extends Maybe {}
> > >
> > > This is exactly the thing I'm worried about.
> > >
> > > Say I want to add something like logging to the None type.
> > > Now your sealed and final classes prevent me from defining MyNone
> > > extending None even though it would be 100% compatible with None.
> > >
> >
> > I just want to note that this has nothing to do with Maybe made sealed
> > (which seems legit), only with None made final (which... could be
> debated,
> > but unrelated to the RFC at hand).
> >
> > Regards,
> >
> > --
> > Guilliam Xavier
> >
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Draft] Sealed Classes
; in S.O.L.I.D.[0] if PHP were to offer the > following three (3) things, all of which can be found in Go, and I am sure > other languages: > > 1. Class embedding[1] — Allows one class to embed another and immediately > have access to all its properties and methods, and also to be able to > extract an instance of that embedded class. It is called "Type embedding" > in Go. > > 2.Type definitions[2] — A typedef would allow developers to define > constrained versions of existing types, such as `FiveStarRating` which > could only contain 1, 2, 3, 4 or 5, or types that identify a signature, for > example as `ConvertToString` which could require a closure that implements > `func(mixed):string`. In Go you can compose other types to create new > types, but I'm not sure if those other type of types could apply to PHP, at > least as it currently exists, and especially because it is not a compiled > language. > > 3. Structural typing[3] — Basically interfaces that can be implemented > implicitly rather than explicitly. For example, if I wanted to implement a > Stringable interface that requires a ToString():string method then > structural typing would allow me to implement that interface simply by > adding a ToString() method instead of requiring me to also add "implements > Stringable" to the class definition. > > Those three features are all killer language features and would make great > additions to PHP. IMO, of course. > > #fwiw > > -Mike > > [0] https://stackify.com/solid-design-open-closed-principle/ > [1] https://travix.io/type-embedding-in-go-ba40dd4264df > [2] https://go101.org/article/type-system-overview.html > [3] > https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/ < > https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/> -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2
On Thu, Mar 25, 2021 at 10:38 AM Olle Härstedt
wrote:
> 2021-03-25 15:23 GMT+01:00, Christian Schneider :
> > Am 25.03.2021 um 14:29 schrieb Mark Randall :
> >> On 25/03/2021 09:28, Rowan Tommins wrote:
> >>> That's not quite what I meant. I meant that you can't say "capture by
> >>> default, but this variable is definitely local".
> >>
> >> I think if there's one argument against, this would be it, but IMHO it
> is
> >> a weakness in PHP as a whole.
> >
> > I'm not sure if I misunderstand what you're saying but to me it is one of
> > the greatest things about PHP that everything is local by default (minus
> a
> > narrow set of well-known and easily enough recognizable things).
> >
> >> The solution would be adding JS-like let / const statements. Which would
> >> be a benefit to other things too.
> >
> >
> > I disagree that this is the solution. I think JS had to add var and later
> > let because of the unfortunate decision to have C-like scoping rules.
> > Making scoping in PHP more complex to be able to repeat this mistake in
> some
> > form seems ill-advised to me.
> >
> > - Chris
>
> You could make the change that *all* variables are now block-scoped,
> not function-scoped. That would make auto-capture less dangerous, but
> I don't know how much code it would break.
>
>
The BC implications would be huge, not to mention that it wouldn't be a
good idea anyway (at least in my opinion). The following would no longer
work:
if($check){
$match = true;
} else {
$match = false;
}
//stuff
if($match){...}
Yes, that could be done in a way that works with block scoping, but the
fact that PHP has never been blocked scoped means there would be a LOT of
code that would break if it was.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
On Thu, Mar 25, 2021 at 1:14 PM Mike Schinkel wrote:
> > On Mar 25, 2021, at 12:50 PM, Rowan Tommins
> wrote:
> >
> > On 25/03/2021 15:02, Mike Schinkel wrote:
> >> Can you please clarify why "function(...) use(...) {...}" can't be
> their solution when someone needs by-reference capture?
> >
> >
> > For the same reason - or lack of reason - why it can't be the solution
> when they need by-value capture. In other words, whatever reason people
> have for wanting this RFC.
>
> Are you proposing auto-capture but one that is note able to change the
> variable's value in the outer scope?
>
> Since code is worth 1000 words, here is an example of what I think you are
> saying:
>
> $x = 1;
> example(fn() {
>echo $x; // This would print "1"
>$x = 2;
>echo $x; // This would print "2"
> });
> echo $x; // This would still print "1"
>
> If that is what you are saying — which I did not get from your prior
> arguments — then I myself would be fine with "by-value" capture.
>
> What I like about the RFC is being able to omit the use(...) when
> referencing (reading) a variable inside the closure that come from the
> outer scope. But almost all of my use-cases would work fine with by-value
> semantics, and for the rest I could use "function(...)use(...){...}."
>
> That said, I again suggest this we could omit the "use" keyword for short
> functions:
>
> // 2nd set of parens acts as an implied "use":
> example( fn()(&$var) => $var = value() );
>
>
That wouldn't work though if example expects a callback with a defined
signature. "Use function() use()" in that case might be a valid solution,
but just wanted to throw it out there. Silly example:
$counter = 0;
array_map(fn($a) => {$counter++; return $a+1},$array);
If you tried to pass in $counter as a parameter, it would fail.
> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
On Thu, Mar 25, 2021 at 12:47 PM Rowan Tommins wrote: > On 25/03/2021 15:05, Deleu wrote: > > > * Because it's shorter, people will decide it's the "better" version, > > > when they don't actually need any variable capture. An explicit syntax > > > like "use(*)" instead makes this a deliberate choice. > > > > Does this mean you agree that people (PHP users) are very likely to > > like/enjoy/"think it's the better version", but you still object to it > > because people will like the new syntax so much that they will use it > > even when they don't need auto-capture? > > > No, it does not. > > I think that people who have no idea how either version of the syntax > works will decide that the keyword "fn" is easier to type than > "function", and not realise the far-reaching effect this can have on > their code. > > I don't think you should keep a function from developers because some people might use it incorrectly. Make sure it is documented properly and stop worrying about people that ignore the documentation. > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
On Thu, Mar 25, 2021 at 11:23 AM Olle Härstedt
wrote:
> 2021-03-25 16:02 GMT+01:00, Mike Schinkel :
> >
> >
> >> On Mar 25, 2021, at 10:41 AM, Rowan Tommins
> >> wrote:
> >>
> >> On 25/03/2021 12:31, Nuno Maduro wrote:
> >>
> >>> The reason why we believe the vast majority of PHP Developers are going
> >>> to
> >>> appreciate this RFC is because multi-line short closures (aka
> >>> Auto-capturing multi-statement closures) *are more simple, shorter to
> >>> write, and prettier to read *— and the community love these changes as
> >>> proven on "property promotions", "one-line short closures", etc.
> >>
> >>
> >> My main point was that the RFC needs to spell out this argument, rather
> >> than taking it for granted that everyone agrees on "those situations
> where
> >> that is warranted".
> >>
> >> Most of the current text should be summarised in a "syntax choices"
> >> section somewhere near the end. I would like to see much more space
> >> devoted to:
> >>
> >> * Why we need this feature. What has changed since it was left out of
> the
> >> arrow functions RFC? What problems is it addressing? Why do you think it
> >> is the best approach to those problems?
> >> * The exact semantics proposed: How will the variables to be captured be
> >> determined? Will it distinguish variables which are written before
> they're
> >> read, and if so how is that defined? Can auto-capturing closures be
> >> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from
> the
> >> outermost scope? And so on...
> >>
> >>
> >>> Besides, one advantage of this RFC is that it is consistent with the
> >>> current syntax of the language and with the short-functions RFC[2]. For
> >>> example, by proposing that "fn" keyword indicates a function will
> >>> auto-capture variables, by value.
> >>
> >>
> >> While it's a cute rationalisation, there's no intuitive reason why "fn"
> >> should have that meaning; we could pick any aspect of the current arrow
> >> function syntax and say "the 'fn' keyword means that".
> >>
> >>
> >>
> >>> On the other hand "use (*)" has no usages / or current meaning in the
> >>> language.
> >>
> >>
> >> This is a straw man argument. I could equally say that "fn() { } has no
> >> usages or current meaning in the language" - of course it doesn't, we
> >> haven't added it yet!
> >>
> >> The "function use() {}" part of "function use(*) {}" has a
> >> well-established meaning, and "*" to mean "everything" is a notation
> >> developers are likely to be very familiar with.
> >>
> >> The two disadvantages I see with using "fn" as proposed are:
> >>
> >> * Because it's shorter, people will decide it's the "better" version,
> when
> >> they don't actually need any variable capture. An explicit syntax like
> >> "use(*)" instead makes this a deliberate choice.
> >
> > And yet adding " use (*)" makes the syntax longer, which goes against
> one of
> > the goals many people have for it: to be shorter.
>
> I don't understand why this is a target in the first place. Shorter
> does not mean more readable, and readable is more important than
> writable.
>
I'm a bit confused on why "shorter" is such an important requirement as
well. We aren't in a situation where memory is at a premium and we have to
take shortcuts to get our code to fit in the available storage. I also
assume that none of us are such slow typers that there is a material
difference between the options. On top of that, most IDEs worth anything
have autocomplete options that make it moot.
I agree that shorter definitely does not always mean more readable. If so,
we'd be taught to give all of our functions and variables single character
names instead of names that were descriptive.
I'm totally in favor of auto capture with the fn() syntax, but I think the
fact that its shorter is not the best argument to support it.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
On Wed, Mar 24, 2021 at 5:26 PM Mark Randall wrote:
> On 24/03/2021 21:00, Rowan Tommins wrote:
> > As Christian says, automatic capture is a dramatic change to the
> > language's scoping rules, and IMHO requires a more thorough
> > justification on why the current syntax is burdensome. As I've said
> > previously, my naive impression is that a long list of captured
> > variables ought to be as bad a code smell as a long list of parameters;
> > I'm willing to be proven wrong on this, but nobody has yet stepped
> > forward with a real-life example.
>
> Automatic capture ceased to be a dramatic change from PHP the day after
> short closurers were introduced. So they've been a part of PHP for years
> now.
>
> I hit long lists of use() repeatedly, almost always because I need to
> perform a series of operations within a callback, prime examples are
> database transactions and using throw-aware buffering handlers.
>
DB transaction is one place I have a long list of use parameters as well.
Since the goal is to do as much before we start the transaction as
possible, I always end up with a lot of variables resulting from that prep
work that I need to utilize inside the transaction callback. My gut tells
me the use-cases for long use lists that don't indicate code smell are
pretty small though.
> In general, anything that needs to wrap a code block in a complex set of
> instructions before and after.
>
> To give my own example, earlier this week I wrote the following:
>
> $x = function () use ($to, $library, $thread, $author, $title,
> $library_name, $top_post) { ... }
>
> That was just to get those variables inside a callback that could be
> invoked inside a throw-aware buffering helper.
>
> I believe that by explicitly stating my intent to use auto capture by
> using fn() { ... } that my code would have been cleaner with less noise.
>
> If I thought otherwise, I would be under no obligation to use them and
> could use function() { ... } instead.
>
I agree. I think as long as we make it clear to users that function() does
not provide auto capture, but fn() does, we're fine. In the same way that
JavaScript make it clear that function(){} changes the meaning of "this"
while () => {} does not. The fact that they behave differently like that is
great in my opinion. I use function(){} when I want the changed context
(like event listener callbacks) and () => {} when I know I only need access
to the parent context and don't care about any possible redefinition.
>
> For me auto capture is a solid +1.
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2
On Wed, Mar 24, 2021 at 1:34 PM Christian Schneider
wrote:
> Am 24.03.2021 um 18:15 schrieb Chase Peeler :
> > I guess my one question would be why we didn't support auto-capture when
> we
> > first implemented anonymous functions, and if there was a reason, why
> does
> > that no longer apply?
>
> My guess would be that it was seen as one of PHP's big strength that
> variables don't just leak into other contexts but that it has to be done
> explicitly.
>
> Now with arrow functions both the benefit of auto-capturing is bigger
> compared to the actual function 'body', it normally only spans a line or
> two and (for me personally) the absence of {} also kind of make the leakage
> fit my mental model more easily.
>
> For these reasons I think I lean towards -1 for both
> https://wiki.php.net/rfc/short-functions <
> https://wiki.php.net/rfc/short-functions> and
> https://wiki.php.net/rfc/auto-capture-closure <
> https://wiki.php.net/rfc/auto-capture-closure> as they add more syntax
> without (IMHO) a huge benefit.
>
> You might be able to convince me otherwise though ;-)
>
I don't really have anything against auto-capture, was just kind of
curious. I guess it is somewhat similar to how x = function(){...} and x =
() => {} work in javascript with respect to "this".
I do think it makes sense to only do auto-capture on the short syntax, so
that you still have the ability to fallback to the long syntax if you don't
want auto-capture, since there are definitely use-cases where it wouldn't
be make sense.
,
> - Chris
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2
On Wed, Mar 24, 2021 at 1:02 PM Nikita Popov wrote: > On Wed, Mar 24, 2021 at 5:20 PM Larry Garfield > wrote: > > > Greetings, Internalians. > > > > Some months back I proposed an RFC for short functions. > > > > https://wiki.php.net/rfc/short-functions > > > > After some discussion, I put it on hold to ensure that it was compatible > > with the other discussion floating about around an alternate syntax for > > multi-line closures that did auto-capture. It's important that the > syntax > > of both proposals is consistent. > > > > Nuno Maduro and i have talked recently and worked out the syntax that is > > consistent between both proposals. That takes 'fn' off the table for > > short-functions, for reasons discussed in both RFCs. > > > > To that end, I offer: > > > > 1) The updated short-functions RFC: > > https://wiki.php.net/rfc/short-functions > > > > 2) A new RFC, code by Nuno, for auto-capturing multi-statement closures: > > https://wiki.php.net/rfc/auto-capture-closure > > > > These are separate RFCs and at this time we plan to send them to separate > > votes, but I list them together to demonstrate that they have been > > developed in a mutually-compatible way. > > > > Further details in the auto-capture-closure RFC. > > > > Could you please create two separate threads for these RFCs? > > Nikita > I guess my one question would be why we didn't support auto-capture when we first implemented anonymous functions, and if there was a reason, why does that no longer apply? -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] Fibers
On Mon, Mar 22, 2021 at 2:22 PM Dan Ackroyd wrote: > On Fri, 19 Mar 2021 at 20:53, Levi Morrison via internals > wrote: > > I hope others would > > play with it more as well if we had more time. Any objections? > > Yes, I object. > > You've been around PHP internals long enough to see the drama has > occurred on other RFCs where people have been > cajoled/pressured/threatened to either suspend votes or withdraw RFCs. > > I agree. I think it puts the RFC author is a bad position too since they risk upsetting others no matter what they choose to do. > Although this RFC is reasonably free from drama, I think it was wrong > for you to ask for an extension regardless of the current voting. Not > only is it improper on its face, but it sets a bad precedent for more > drama filled RFCs. > > cheers > Dan > Ack > > btw I would prefer that all RFC votes were longer (e.g. 4 weeks for > all decisions that don't have an external time constraint), but > changing the end time during the vote is bogus. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
On Mon, Mar 22, 2021 at 1:22 PM Rowan Tommins wrote: > On 22/03/2021 16:52, Aleksander Machniak wrote: > > On 22.03.2021 16:41, Rowan Tommins wrote: > >> That code will never do anything useful. > > I already proved it is useful, regardless of it's name/intention. > > > You have proven no such thing. If that function is saving you from > errors, it is completely by accident. > > Even if it is by accident, removing or changing the behavior of the function is guaranteed to make something that currently works (by skill or by luck) and risk it no longer working. > The same effect can be achieved using base64_encode() and > base64_decode(), or bin2hex() and hex2bin(), or any other function that > takes a series of bytes and applies an arbitrary encoding to it. > > It could also be achieved by using a binary column type in the database, > because the values you have stored are not useful as strings; they might > as well be encrypted. > > Given the sequence of bytes "\xE3\x82\zB0", which is a valid UTF-8 > string representing U+30B0 KATAKANA LETTER GU グ calling utf8_encode() > will result in the sequence of bytes "\xC3\xA3\xC2\x82\xC2\xB0", which > is the UTF-8 representation of the following Unicode code points: > > - U+00E3 LATIN SMALL LETTER A WITH TILDE ã > - U+0082 CONTROL: BREAK PERMITTED HERE > - U+00B0 DEGREE SIGN ° > > This is clearly gibberish, and bears no relationship to the original > string; it is what is generally referred to as "mojibake". > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Autoloader Classmap
On Tue, Mar 16, 2021 at 8:02 AM Mark Randall wrote: > On 15/03/2021 22:18, Levi Morrison via internals wrote: > > Like any other case insensitive symbol PHP works with that comes from > > userland, I would lower it in the engine's side of things. I would not > > push the lowercase requirement on the API. > > That was the first design, however it required re-creating the array > with potentially many thousands of new strings which slowed it down > considerably. > > As I envisenge this to be used with machine generated data, having it > use lowercase would not be an issue. > If lower case key names weren't a requirement for the user, but the engine worked on lower case keys, how would something like this behave: $map['myClass'] = '/path/to/lib/myclass1.php' $map['myclass'] = '/path/to/lib/myclass2.php' > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature
On Thu, Mar 11, 2021 at 10:37 AM Larry Garfield
wrote:
> On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> > Hi Victor,
> >
> > It does not contradict because it does not cover two different aspects.
> > First, return types specify the types of to be returned values. Second,
> > this request proposes a shorthand technique to avoid writing a single
> > line code multiple times. Third, it is similar to default argument
> > values that are also typed.
> >
> > Cheers!
>
> Greetings. First, please don't top post. This is a bottom-posting list.
>
> As to your proposal, it's a bit hard to follow because it sounds like
> you're suggesting an implicit "return of nothing" built on union types,
> when based on your follow ups what I think you're suggesting is something
> more like this:
>
> function foo(int $bar = 4): int = 0 {
> if (is_even($bar)) {
> return; // Implicitly returns 0
> }
> return $bar * 2;
> }
>
> That is, allowing a default return value. Union types aren't part of the
> picture.
>
> I can see how you got to the idea, but honestly I am not a fan.
> Primarily... I've never run into the situation you describe where multiple
> early-returns would have the same value. Perhaps it's just because in
> those cases I end up combining the conditionals with an ||, but I don't see
> the problem you describe. Different code paths should result in different
> results, or else why are they different code paths?
>
> So, code that's doing that I'd be suspicious of to begin with.
>
>
There are times, for the sake of readability, where I might break things up
into multiple if statements instead of combining them with an OR.
Sometimes you need to do additional work between conditionals as well:
if($id == 0){
return null;
}
$record = $db->get($id);
if(empty($record)){
return null;
}
Regardless, I think your solution below works just fine.
> Even if you did end up in such a situation, since you're dealing with a
> static value, setting the default internally within the function is trivial:
>
> function foo(int $bar = 4): int {
> $default = 0;
> if (is_even($bar)) {
> return $default;
> }
> return $bar * 2;
> }
>
> So basically, in the few cases where this isn't a code smell, it's
> unnecessary.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] 回复：Re: [PHP-DEV] [VOTE] Fibers
On Thu, Mar 11, 2021 at 8:56 AM 韩天峰 wrote: > Hi, > I am come from Chinese, we may have some cultural differences, and there > may be some difficulties in communication. I try to express my opinion. > To be precise, the fiber can only be used for amphp and reactphp or other > event-driven asynchronous IO frameworks developed using php.The RFC > does not mention how an extension uses fiber. > Fiber is not like threads or processes of operating system. It is not > parallel, nor is it concurrent. This requires an event-driven scheduler to > have practical value.Currently php does not have event-driven > support. So normal web developers don’t know how to use fiber.It is > for developers of asynchronous io programming. > I just suggest first to provide a PECL extension like > ext-event/ext-libevent, no need to be integrated into php now.Swoole > is also provided to users as a PECL extension. > > I want to answer this in a different way than Aaron did. Let's assume that this is correct. No one will EVER use fibers except amphp and reactphp. Let's also assume that it would work just fine as an extension (which Aaron has shown already is not the case). If someone is willing to do the work to add this to core, we aren't trading off other features in order to add it, and it doesn't cause BC breaks or other bugs, what is the reason to not add it? > > > > --原始邮件-- > 发件人: "Peter Stalman"; > 发送时间: 2021年3月11日(星期四) 下午2:37 > 收件人: "韩天峰"; > 抄送: "Aaron Piotrowski"; "php internals"; > 主题: Re: [PHP-DEV] [VOTE] Fibers > > > > OnWed.,Mar.10,2021,02:16韩天峰,< > ra...@swoole.comwrote: > > > Iamafraidthatfibercanonlybeusedintheamphpframeworkandisof > novaluetootherphpprojects. > > > Hi, > > > Idliketoseeyouelaborateonthispoint.Areyouabletoprovide > anythingtobackupthisclaim? > > > Idontseeanythingthatisspecifictoamphp,notanythingtolimititto > > theiruse.FibersalsoexistoutsideofPHP,whileamphpdoesnt. > > Thanks, > Peter -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] noreturn type
On Wed, Mar 10, 2021 at 2:22 PM Matthew Brown wrote: > On Wed, 10 Mar 2021 at 13:55, Rowan Tommins > wrote: > > > I am however slightly confused by what exactly the implementation > > checks, and when. Is it actually looking for "exit" and "throw" > statements? > > > > No. Any function annotated with `: noreturn` causes the engine to insert > a ZEND_VERIFY_NORETURN_TYPE op at the end of the function's operands. > > If the Zend engine hits that operand — which only happens if a throw/exit > *hasn't* been encountered — it emits a TypeError. > > The other thing I'd like to mention is that PHP's implementation of > > "void" consists mostly of checking that there is no return statement, so > > a separate keyword of "noreturn" may well cause confusion. I would > > personally prefer the name "never" for this reason. > > > > If a significant number agree I can add a secondary vote on noreturn vs > never, but never introduces more of a BC risk. > > I think the difference between void and noreturn is pretty clear, but, if never is more clear, perhaps neverreturn would be an option that would be less likely to have BC risks. Just to throw out some additional ideas, why not two possible types: throws and exits? Don't have any strong opinions on that, but figured I'd add it to the discussion. > Best wishes, > > Matt > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Add __toString() to DateInterval
On Wed, Mar 3, 2021 at 8:42 AM Andreas Heigl wrote:
>
> Am 03.03.21 um 14:24 schrieb Moritz Friedrich:
> >
> >
> >> Am 03.03.2021 um 14:01 schrieb Andreas Heigl :
> >>
> >> I'd rather see those classes as ValueObjects that should not have to
> >> take care about their external representation. And a custom Formatter
> >> that handles all the weird edge cases as a separate entity would be a
> >> much easier to maintain approach. And such a Formatter can easily be
> >> build in userland (I think I wrote one myself at one point) and so the
> >> maintenance-burden would also not be added to internals.
> >>
> >> That would also apply to the DateTimeInterval::format() method but that
> >> would mean a massive BC break so it is most likely out of the question.
> >> Nevertheless I would prefer an external library to handle all those
> >> formatting issues and treat the DateTime lib as internal ValueObjects
> >
> > I’d like to respectfully disagree. If we were to go down the ValueObject
> route, DateTime/DateInterval should not be able to create new instances
> from formatted strings in the first place. PHP Date classes have always
> been intertwined with their output formatting however, so this is how the
> ecosystem uses them. In that sense, I’d expect DateInterval to be able to
> return the format it was instantiated with, but it isn't.
>
> Well. ValueObjects should be able to create new Instances of themselves
> via factory methods. But that would mean a lot of tweaking at perhaps no
> added benefit.
>
> But TBH: DateTimeImmutable:fromString() instead of new
> DateTimeImmutable() would be awesome... Or even better:
> DateTime::fromString() with DateTimeImmutable as return type
>
>
> > The PHP API may have its warts, but I prefer my warts consistent.
>
> I feel you.
>
> As the other Objects have a format() method why not have a format method
> for DatePeriod as well? It does not need to take a parameter as there
> are no different formats (at least that I could think of).
>
> But I would rather not add more magic (methods) to PHP...
>
>
I wouldn't call utilizing __toString() adding more magic methods to PHP.
It's utilizing a magic method that already exists. I'd also argue that of
all the magic methods, __toString() is probably the least likely to cause
issues.
1.) Core/bundled extensions don't usually have major documentation issues
2.) Even if __toString() functionality isn't properly documented, I'm
guessing (please prove me wrong if I am) that working with string output of
an object that hasn't implented __toString() has hardly any use in
production (not counting tests). As such, if __toString() were to magically
appear (pun intended) the side effects would be minimal.
3.) Unlike some of the other magic methods (__get, __set, __call for
instance) __toString() is basically implementing an interface from a user
perspective.
I personally like the idea of having more explicit methods and then
allowing __toString() to invoke one of those.
I don't know if I like this idea or not, but, just to throw it out there,
when dealing with something like DateTime, you could even support the
ability to set a "default" format that would be utilized by __toString
(with the default format having a default value if not set)
$dt = new \DateTime();
echo $dt; //outputs 2021-01-01T03:15:00-05:00
$dt->setDefaultFormat("Ymdhis");
echo $dt; //outputs 20210101031500
Considering that when I'm doing something and need frequent string
representations of a DateTime that are always the same format, I usually do
$dt = new \DateTime();
$format = "Ymdhis";
echo $dt->format($format);
$s = $dt->format($format);
The only thing you really risk with the setDefaultFormat() option is that
you pass the DateTime to another method and they aren't really sure what is
there and/or override your default format. I think as long as it's well
documented, that could be easy to work around.
function foo(\DateTime $dt){
$currentFormat = $dt->getDefaultFormat();
$dt->setDefaultFormat("m/d/Y");
//stuff
$dt->setDefaultFormat($currentFormat);
}
Again, I'm not sold on such functionality, just throwing out some ideas to
see what others thing.
> Cheers
>
> Andreas
>
> --
> ,,,
> (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl |
> | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org |
> +-+
> | https://hei.gl/appointmentwithandreas |
> +-+
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Inline conditional that returns null if falsy
On Wed, Feb 24, 2021 at 11:35 AM Mike Schinkel wrote: > > On Feb 24, 2021, at 11:27 AM, Chase Peeler wrote: > > On Tue, Feb 23, 2021 at 11:27 PM Mike Schinkel > wrote: > >> > On Feb 23, 2021, at 2:05 PM, Rowan Tommins >> wrote: >> > >> > On 23/02/2021 18:41, Albert Casademont wrote: >> >> Sure, it's not a big deal having to write the ": null" but it doesn't >> add >> >> any value >> > >> > >> > On the contrary, it adds an important piece of information: that the >> default value is "null", rather than "false", or "0", or "new EmptyValue()". >> > For instance, it doesn't seem at all obvious to me that this code >> should produce a null: >> > >> > $items = []; >> > $itemCount = $items ? count($items); >> > >> > I might be more convinced that "null" is the "natural" value if the >> left-hand operand was only checked against null, not "falsiness": in that >> case, you can read it as "if it's null, leave it alone". I'd still be >> inclined towards "too specific to use up more syntax", though. >> >> If you look at it from a software engineering perspective — which is how >> I assume most on this thread have been looking at it — being more explicit >> in the code is probably a better practice than saving a few keystrokes. >> >> OTOH, if you view it from the perspective of a *templating* language — >> which is what PHP was initially created to be, for the web — then the >> reduction in visual noise from omitting ": null" would be a nice plus. And >> in the case of templating, the distinction between null vs. false vs. "" >> would be completely moot. >> >> > But PHP isn't just a templating language anymore. > > > It is not? If it is not I think a lot of userland PHP developers never > got that decree. > > I didn't say it COULDN'T be used for templating (although even then I'd suggest utilizing a library like smarty or twig) but that it is a lot more than that. I'd also say that, good or bad, the direction of the language in the last 15+ years has been to make it a robust language that can be used for more than just templating. > If PHP currently had support for omitting the third argument on the > ternary operator, then I'd be against changes that required it given the BC > implications. > > > Can you elaborate on those? > > Well it's pretty obvious. If php currently supported a statement like "$user ? 'online'" then a change that requires the third argument would break every single instance of code that didn't have one and wouldn't provide any functional gains as nothing prevents people from adding on the ": null" if they want to. It's a moot point, though, because PHP doesn't support it. I just included that statement to give context to my views - that I'm not automatically in favor of changes just because they enforce better development practices. > I think just dropping the need for a third argument on the existing > ternary operator is a bad idea. > > I'm ambivalent when it comes to creating a new symbol to support this > behavior (e.g. ?!). I don't really think it's necessary, but, I don't think > it hurts anything either. > > > >> Repeating code similar to that from the message sent by David Rodrigues >> you can see that eliminating the ": null" is less noisy: >> >> ... >> ... >> >> Although one ":null" eliminated is not that significant, PHP templates >> for generating HTML are notorious for having conditionals littered >> throughout, with tens if not hundreds of cases per file. So being able to >> drop the ":null" would be a really nice addition for templating. >> >> To emphasize this feature address templating use-cases one might argue >> that dropping the "or" case of the trinary might only be supported when >> between single-line "" delimiters. >> >> -Mike >> >> P.S. Of course making it work differently between single-line delimiters >> and elsewhere would create inconsistency in the language so I probably >> would not actually argue that, I was just trying to make a rhetorical point. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >> > > -- > Chase Peeler > chasepee...@gmail.com > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Inline conditional that returns null if falsy
On Tue, Feb 23, 2021 at 11:27 PM Mike Schinkel wrote: > > On Feb 23, 2021, at 2:05 PM, Rowan Tommins > wrote: > > > > On 23/02/2021 18:41, Albert Casademont wrote: > >> Sure, it's not a big deal having to write the ": null" but it doesn't > add > >> any value > > > > > > On the contrary, it adds an important piece of information: that the > default value is "null", rather than "false", or "0", or "new EmptyValue()". > > For instance, it doesn't seem at all obvious to me that this code should > produce a null: > > > > $items = []; > > $itemCount = $items ? count($items); > > > > I might be more convinced that "null" is the "natural" value if the > left-hand operand was only checked against null, not "falsiness": in that > case, you can read it as "if it's null, leave it alone". I'd still be > inclined towards "too specific to use up more syntax", though. > > If you look at it from a software engineering perspective — which is how I > assume most on this thread have been looking at it — being more explicit in > the code is probably a better practice than saving a few keystrokes. > > OTOH, if you view it from the perspective of a *templating* language — > which is what PHP was initially created to be, for the web — then the > reduction in visual noise from omitting ": null" would be a nice plus. And > in the case of templating, the distinction between null vs. false vs. "" > would be completely moot. > > But PHP isn't just a templating language anymore. If PHP currently had support for omitting the third argument on the ternary operator, then I'd be against changes that required it given the BC implications. I think just dropping the need for a third argument on the existing ternary operator is a bad idea. I'm ambivalent when it comes to creating a new symbol to support this behavior (e.g. ?!). I don't really think it's necessary, but, I don't think it hurts anything either. > Repeating code similar to that from the message sent by David Rodrigues > you can see that eliminating the ": null" is less noisy: > > ... > ... > > Although one ":null" eliminated is not that significant, PHP templates > for generating HTML are notorious for having conditionals littered > throughout, with tens if not hundreds of cases per file. So being able to > drop the ":null" would be a really nice addition for templating. > > To emphasize this feature address templating use-cases one might argue > that dropping the "or" case of the trinary might only be supported when > between single-line "" delimiters. > > -Mike > > P.S. Of course making it work differently between single-line delimiters > and elsewhere would create inconsistency in the language so I probably > would not actually argue that, I was just trying to make a rhetorical point. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Replies on lists.php.net
On Tue, Feb 23, 2021 at 10:27 AM Ben Ramsey wrote: > > On Feb 23, 2021, at 09:21, Larry Garfield > wrote: > > > > On Mon, Feb 22, 2021, at 4:26 AM, Christian Schneider wrote: > >> Am 15.02.2021 um 13:20 schrieb Pierre : > >>> I noticed I receive almost all your replies to the list along with a > duplicated copy addressed to me or other conversation participants, I think > you always click "reply to all" instead of "reply to list" in your mail > client. > >> > >> I think if our intention is that the default reply should go to the > >> list then the mailing list should be configured to include a > >> Reply-To: "php internals" > >> header which it currently does not, right? > >> > >> This would make it harder to send a reply directly to the author (in > >> some clients you have to click reply and then copy the address) but it > >> would not depend on the reply-to-list feature not all mail clients have. > >> > >> - Chris > > > > +1 Endorse > > > Also +1 > > I had no idea that it was double-sending messages to folks when I did > reply-all. My mail client must filter the messages appropriately so that I > only see one message, and I don’t have a reply-to-list option. > > Cheers, > Ben > > > The gmail web client has the sender as the reply-to, and the list in the cc (at least in this case). On the receiving side, I don't get duplicates, so I assume gmail is smart about filtering those out. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Inline conditional that returns null if falsy
On Tue, Feb 23, 2021 at 9:31 AM Nikita Popov wrote: > On Fri, Feb 12, 2021 at 8:25 PM David Rodrigues > wrote: > > > Hello! > > > > It is just a suggestion to be discussed. > > > > A lot of places on my projects I have codes like: > > > > $companies = $user->companies->count() > > ? new Collection($user->companies) > > : null; > > > > So $companies will be null except if the user has companies. > > > > My suggestion is create some kind of inline conditional to works like > that: > > > > $companies = $user->companies->count() => new > Collection($user->companies); > > > > If the conditional ($user->companies->count()) is true, then will return > > the value (after =>), else will be null. > > > > In my current work project, I have more than 100+ occurrences like that. > > > > So some more examples: > > > > $userCategory ? $userCategory->getTitle() : null > > -> It could be optimized to the new nullsafe operator > > $userCategory?->getTitle() > > > > return $languageFirst instanceof LanguageExperience > > ? $languageFirst->title : null; > > -> This not, with my suggestion we have: > > return $languageFirst instanceof LanguageExperience => > > $languageFirst->title; > > > > The => is just a suggestion, other options using existing keywords is: > > return expr() then output(); > > return expr(): output(); > > > > I do not know if other languages support something like that. > > > > Thanks! > > > > There's a limited budget for this kind of syntax sugar, and we already have > ?:, ??, ??=, ?->. I don't think there's space for yet another shorthand > conditional syntax. > > I don't really have any strong feelings on this either way, but ?! seems like a logical choice if it was to be implemented. > Note that => cannot be used for this purpose, as it is already used for > array literals. > > Regards, > Nikita > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] Enumerations
On Wed, Feb 17, 2021 at 12:41 PM Ben Ramsey wrote: > > On Feb 17, 2021, at 09:26, Chase Peeler wrote: > > > > On Wed, Feb 17, 2021 at 10:09 AM Rowan Tommins > > wrote: > > > >> On 17/02/2021 14:30, Larry Garfield wrote: > >>> The Enum RFC has been approved. > >> > >> > >> Thank you and Ilija so much for putting in the effort to make such a > >> carefully thought-through proposal, and I'm really looking forward to > >> being able to use it. > >> > >> I realise not everyone agrees with the approach, but am hopeful that it > >> can be expanded on in future proposals to add a lot of power to the > >> language. > >> > >> > > Glad to see this passed. I definitely would have voted for it if I had a > > vote. The only thing I wish had been included was the ability to use them > > as array keys, but definitely don't think the lack of that would be a > > reason to vote against it - especially since the possibility is still > open > > in the future and adding it wouldn't cause any BC issues. > > > There’s an RFC for that. ;-) > > https://wiki.php.net/rfc/object_keys_in_arrays > > Cheers, > Ben > > If that were to not pass, though, it seems supporting enum cases as keys would be worth exploring. Fully support allowing all objects as keys though. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: [VOTE] Enumerations
On Wed, Feb 17, 2021 at 10:09 AM Rowan Tommins wrote: > On 17/02/2021 14:30, Larry Garfield wrote: > > The Enum RFC has been approved. > > > Thank you and Ilija so much for putting in the effort to make such a > carefully thought-through proposal, and I'm really looking forward to > being able to use it. > > I realise not everyone agrees with the approach, but am hopeful that it > can be expanded on in future proposals to add a lot of power to the > language. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Glad to see this passed. I definitely would have voted for it if I had a vote. The only thing I wish had been included was the ability to use them as array keys, but definitely don't think the lack of that would be a reason to vote against it - especially since the possibility is still open in the future and adding it wouldn't cause any BC issues. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: Proposal: namespace the SPL
On Thu, Feb 11, 2021 at 1:08 PM Lynn wrote: > > > On Thu, Feb 11, 2021 at 6:55 PM Levi Morrison via internals < > internals@lists.php.net> wrote: > >> I don't know the answer to that question. However, I don't think we >> should add a deprecation on the very first version that we add the >> aliases anyway. I think that would make for a bad upgrade experience >> from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the >> release cycle so there are at least a few versions for people to >> organically change their code without triggering any notices of any >> kind. >> > > I would very much prefer this to be deprecated in the same version. This > way you prevent the confusion of which of the two to use and have people > implement the one we already know is going to be removed. Deprecations do > not make it a bad upgrade experience at all. Quite the opposite in my > opinion, they hint to me nice and early on which parts of the code base I > have to adjust. The earlier the better. > I'm really ambivalent about when they are introduced, but I actually think I agree with you. I know it's very much just a personal anecdote, but since I don't turn deprecation notices on until I'm ready to actually look for and fix them, I don't find them obtrusive at all. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: Proposal: namespace the SPL
On Thu, Feb 11, 2021 at 12:23 PM Levi Morrison via internals < internals@lists.php.net> wrote: > On Thu, Feb 11, 2021 at 9:57 AM Mark Randall wrote: > > > > On 11/02/2021 16:39, Levi Morrison wrote: > > > Let me know what you think. I am hopeful this approach will work > because: > > > 1. It is focused on a specific area which already has an established > > > "namespace", but in name-only (not technically). > > > 2. It does not try to solve the larger problem, which has a lot of > > > disagreement. > > > 3. I will be proposing new types for ext/spl soon (`ReverseIterator` > > > and an array iterator that is more efficient than `\ArrayIterator`), > > > and Tyson Andre has already proposed `CachedIterable` and company > > > which is in `ext/spl`, so this space has active development. > > > > > > Thank you for your time. > > > > > > > Do you want a dumping ground? Because this is how you create a dumping > > ground :-) > > > > If we're going to start putting things into namespaces (and we should) > > then we should absolutely avoid repeating the mistakes of the past by > > dumping completely unrelated things together. > > I agree, which is the point of accepting things in a narrow scope. > Data structures and iterators go hand-in-hand, as many iterator > implementations are directly connected to the internal implementation > details of the related data structure. There are other iterators, and > as long as they are general purpose they are fine too. These things > are related, not unrelated. > > > If SPL\ is to exist (and personally I think SPL is so cancerous, it > > shouldn't) then IMO it must absolutely be SPL\iterators. > > As mentioned in the previous point, iterators and data structures > belong together. It does not make sense to separate the implementation > of FixedArray and its iterator into two different namespaces; they are > one cohesive unit. > > Lastly, if we don't adopt a namespace soon, what will new names be? I > can guarantee it will be something like `SplReverseIterator`, not > `SplIteratorReverseIterator`. It won't be > `SplDatastructureCachedIterable`, it would be something like > `SplCachedIterable` (or `CachedIterable`, ugh). > > As you see, "Spl" _is_ the namespace. Any more or any less is > incongruent with what we have. This is why I am hopeful that > _specifically_ using "Spl" for these specific types can reach > agreement; all we are changing is `Spl$thing` to `Spl\$thing`. > > I think Spl makes sense (there might be a debate over whether it should be Spl or SPL though). How feasible is it to create generate a deprecation notice when the global version is used? I assume the hope is to eventually move away from using those, and I don't think that's a horrible BC break given that users have enough time to prepare for it. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions
On Fri, Feb 5, 2021 at 6:46 PM David Gebler wrote: > > Floats (doubles) can accurately represent all integers up to 2⁵³, so > there > > is no inaccuracy in this range; the result from round() or floor() could > > therefore be safely passed to (int) even if the cast operator checked for > a > > 0 fractional part, which is what I'm advocating for. > > Generating a warning on explicit casts of (non-integer) floats to int would > IMO make no sense at all, it would put PHP at odds with other major > languages such as C, Python and Java and go against normal, reasonable > expectations of how a programming language behaves. > > You said in an earlier comment "it's better to be explicit about your > intent", but doing something like (int)3.5 *is* being explicit about your > intent - and truncating casts on float to int is the widely established > norm. > > This was exactly my reservation about deprecating this behaviour even as an > implicit cast - in my mind it isn't a bug or flaw, it's there by design. > > If developers want to round/ceil/floor/do whatever with a float prior to > using it as an int, they already have that option and the greatest > flexibility. > > At least with the implicit case, I understand the motivation and argument > for bringing coercion more in line with strict typing behaviour and > catching cases where such a cast may not have been intentional (though I > still think a warning is too high an error level for this and would favour > a notice or deprecation, were it to be done at all). > > A notice is fine, but PLEASE don't make it a warning. I'm in the process of upgrading to 8.0 right now and I have so much code that works perfectly fine but generates warnings (undefined array key for example - in 99.9% of the cases where an array key is not defined, the null value that used to result from that was perfectly fine). > > On Fri, Feb 5, 2021 at 12:52 PM Benjamin Morel > wrote: > > > On Fri, 5 Feb 2021 at 11:56, AllenJB wrote: > > > > > (And after checking the manual, I'd also note here that round() also > > > returns a float, so how exactly does your example here work? Is it only > > > OK to explictly cast a float that's the return value of a function? Or > > > only explictly cast a float if the fractional part is .0? Is that > viable > > > given the "inaccuracy" of floats? Or would it be better for PHP to have > > > some non-range/accuracy-sensitive representation for integers (and > > > decimals) here?) (and now we're getting into "why are we still using > > > floating point math by default in 2021" territory, so I'll stop right > > here) > > > > > > > Floats (doubles) can accurately represent all integers up to 2⁵³, so > there > > is no inaccuracy in this range; the result from round() or floor() could > > therefore be safely passed to (int) even if the cast operator checked > for a > > 0 fractional part, which is what I'm advocating for. > > > > There are legitimate cases for explicitly casting floats to int. For > > > example floor() outputs a float, but in the context of the domain I'm > > > working I might know that the result is never going to exceed a certain > > > value and want the result explicitly as an int. > > > > > > Perfect, so (int) floor() would work wonders for you, even with the > strict > > casting I'm talking about. > > And if the result does overflow an integer one day, I'm sure you'd be > happy > > to know it by getting an exception, rather than getting silently ZERO: > > > > echo (int) 1e60; // 0 > > > > — Benjamin > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?
On Thu, Jan 14, 2021 at 11:40 AM Larry Garfield wrote: > On Thu, Jan 14, 2021, at 4:29 AM, Kris Craig wrote: > > > > > > > and as explained in the past: if *you guy* ever again contact my > > > > employer asking for the law department beause you think some > bugreport > > > > written late at night with a obfuscated email was from me i will > *find > > > > and fuck* you > > > > > > Wait did somebody actually contact this troll's employer?! Seems like an > > unnecessary escalation to me. I think this may be a perfect example of > the > > timeless wisdom of the phrase, "Do not feed the trolls." > > > > Might be better to just block all of his known emails from the list. If > he > > gets around this by emailing people individually, I agree that publishing > > it here with the email address included would be useful, as it would > enable > > everyone to individually block their emails then. > > > > --Kris > > Point of order. "Don't feed the trolls" may be timeless, but there is > absolutely nothing wise about that saying. It's the "turn the other cheek > when the bully punches you in the face" advice, and it backfires horribly. > > Telling people to individually block an abusive user with many email > addresses is putting all the effort of dealing with an abuser on the > victims. That's the worst possible advice one could give. > > cf: https://peakd.com/community/@crell/why-you-can-t-just-ignore-them > > Please, for the love of all that is holy, expunge "don't feed the trolls" > from your mind. It's counter-productive and destructive advice. > > I agree with this. I'd also add that in this case, we aren't even feeding this troll. He lurks on the list and sends private replies to people. Usually those replies nitpick on something that isn't even the main point of the discussion. The only way to "not feed" this troll would be to not participate at all. > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?
On Thu, Jan 14, 2021 at 9:47 AM Levi Morrison via internals < internals@lists.php.net> wrote: > > > Am 14.01.21 um 03:45 schrieb Dan Ackroyd: > > > > If anyone else receives unpleasant emails from him (or from anyone > > > > else), please either: > > > > > > > > * forward them to the list for all to see. > > > > * forward them to myself, if you'd prefer to not have it dealt with > in public > > > > > > besides again: who do you think you are (forward them to myself) - you > > > confuse different things! > > > > > > * when i write a *private* mail to someone you have > > >no business and "forward them to the list for all > > >to see" is pure bullshit > > > > > > * it's even not permitted by law, if someone feels > > >insultet he can sue me, but it's not permitted > > >to publish private communication unasked > > Note that while this probably varies by location, it is not well > established. You are better off contacting Dan in private, not > forwarding the email. > > Not a lawyer, but I would think any laws around sharing of private communications would apply to forwarding it to any third party, whether that's a distribution group or an individual. > The person in question is clearly subverting their ban, and is abusive > in private and public communication (bugs.php.net is absolutely > public). I think taking legal action is appropriate, as they haven't > stopped simply because they've been banned. > > I think one of the "rules" of the group is that replies should not be made off-list. Now, I think we all make them at times, and there are valid reasons. However, given that rule, we all know that if we do, we risk that private reply being brought back into the public forum. While this person is definitely disruptive and we need to find some way to deal with them once and for all, part of me actually finds their replies humorous because they are just SO out there and unwarranted. They take trolling to a whole new level in my opinion. If we want to avoid possible legal issues, I think we could still send the replies to the list, after removing any contact information that is included, and no one would have any trouble figuring out who it is. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw
On Wed, Oct 28, 2020 at 11:15 AM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> I agree - "it's harder to imagine a scenario in real life where".
>
> From php perspective, swapping parameters in inheritance SHOULD NOT be
> allowed, as without named parameters the parameters are not swapped.
> Also, if the parameters are typed differently, the example is even
> impossible (and nowdays, typed parameters are very common, thus
> "commonly impossible").
>
>
What do you mean they "aren't swapped?"
class A {
public function foo ($str1,$str2){
return strcompare($str1,$str2);
}
}
class B extends A{
public function foo($str2,$str1){
return strcompare($str2,$str);
//or
//return parent::foo($str1,$str2);
}
}
They are swapped in the above example because the code inside B::foo
handles the swapping. And, maybe there is a valid reason that the developer
wanted to emphasize $str2 over $str1 in the subclass.
If we can agree, that implementation is not guaranteed to be called with
> named parameters only, what real world usecase to defend this current
> php behaviour is left?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
>
Considering that parameter swapping prior to unnamed parameters has always
been supported, what unique issue does it represent that requires we solve
it now? Anything done to prevent it would almost certainly be a huge BC
break. As for real world use-cases, I can think of a few:
1.) Developer the subclass wants to make certain parameters optional which
weren't originally at the end of the parameter list
2.) Parent class broke common practices in terms of parameter order
($needle, $haystack vs $haystack, $needle) and they want their subclass to
follow the more commonly used pattern.
3.) The developer of the subclass just wants them in a different order for
some reason that makes sense to them. Maybe they don't need to support
polymorphism. Maybe the idea is that the subclass will be used INSTEAD of
the parent class and any knowledge of the parent class by other programmers
isn't even necessary.
> Michael Voříšek
>
> On 28 Oct 2020 15:57, Rowan Tommins wrote:
>
> > On 28/10/2020 10:45, Michael Voříšek - ČVUT FEL wrote:
> >
> >> https://3v4l.org/X8omS parameters renamed, result with named parameters
> >> is different
> >
> > While it's easy to construct an example where this happens, it's harder
> to imagine a scenario in real life where:
> >
> > * a sub-class overloads the function with different parameter names...
> > * ...that overlap with the original parameter names... (i.e. the call
> will succeed)
> > * ... but not in the same order...
> > * ...where calling with ordered parameters results in the expected
> behaviour (i.e. it's not already incorrect code)
> >
> > It seems more likely in practice that a polymorphic call assuming the
> parameters are in the same order would fail where one assuming they have
> the same names will succeed, e.g.:
> >
> > class A {
> > public function search(string $needle, string $haystack) { ... }
> > }
> > class B extends A {
> > public function search(string $haystack, string $needle) { ... }
> > }
> >
> > $aOrB->search("foo", "foobar"); // incorrect call on instances of B, but
> allowed in every version of PHP
> >
> > $aOrB->search(needle: "foo", haystack: "foobar"); // correct behaviour
> whether instance of A or B :)
> >
>
I agree that this scenario is very contrived. You are looking at a scenario
where multiple examples of poor programming are layered on top of each
other. Trying to prevent such scenarios risks going down a rabbit hole that
removes a lot of freedom from the language.
> >> https://3v4l.org/kgHWf renamed parameter, call with named parameters
> >> does not succeed at all (which violated basic principe of OOP
> >> inheritance at least)
> >
> > This is the case that is explicitly discussed in the RFC:
> https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
> >
> > I'm not sure what more can be said than appears in that summary, and in
> the linked discussion of rejected alternatives. As the RFC says, the
> pragmatic decision was taken to defer these errors to runtime.
> >
> > It's worth noting that since PHP doesn't have checked exceptions, a
> child method throwing an error that it's parent wouldn't is already
> possible and not considered a violation: https://3v4l.org/3m7eo
> >
> > Regards,
> >
> > --
> > Rowan Tommins (né Collins)
> > [IMSoP]
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Compiler Optimizations
On Tue, Sep 15, 2020 at 9:51 AM Benas IML wrote:
> Ah, sorry! Misread your post. Anyways, the compiler doesn't transform
> `\array_keys()` yet, so there's no optimization for that.
>
> As for other compiler optimizations, 2 that I know that the compiler does
> is:
>
> 1. Binary OP evaluation i. e. `2 * 2` does not yield `ZEND_ADD` opcode but
> is instead computed by the compiler directly.
>
> 2. There are special functions that have their own opcodes. You can learn
> more about those here:
>
> https://phpinternals.net/articles/optimising_internal_functions_via_new_opcode_instructions
>
That's a good starting point, thanks.
>
> Best regards,
> Benas
>
> On Tue, Sep 15, 2020, 4:44 PM Chase Peeler wrote:
>
>> I wasn't proposing that my example be supported. I'm totally okay with
>> the fact that it doesn't. My question was about whether or not those kinds
>> of optimizations are documented anywhere so that developers can make sure
>> they don't miss out on them by not fitting the proper pattern.
>>
>> On Tue, Sep 15, 2020 at 9:40 AM Benas IML
>> wrote:
>>
>>> Hey,
>>>
>>> During my free time, I'm implementing that specific `array_keys`
>>> optimization. I'm not planning on supporting cases like yours (i. e.
>>> indirection through a variable) since there's no point in doing that. And
>>> also, it's not feasible to support every use case. Should we also support
>>> cases like this?
>>>
>>> ```php
>>> $a = 'array_keys';
>>> $b = $a(...);
>>> $c = 'b';
>>>
>>> foreach ($$c as $key) {
>>> ...
>>> }
>>> ```
>>>
>>> Obviously not. `\array_keys` optimization will work the same way as an
>>> optimized `strlen` function works.
>>>
>>> That means that the optimization is only going to be applied if the
>>> `array_keys` function is used directly in the `foreach` loop and only if a)
>>> either the namespace is global b) or `\array_keys(...)`/`use function
>>> array_keys` is used.
>>>
>>>
>>> Best regards,
>>> Benas
>>>
>>> On Tue, Sep 15, 2020, 4:23 PM Chase Peeler
>>> wrote:
>>>
>>>> I brought this up on another thread, but it wasn't addressed (which is
>>>> fine, since it was somewhat off-topic). I thought it might be
>>>> worth bringing up in its own thread, though.
>>>>
>>>> In the other thread, someone had mentioned the following compiler
>>>> optimization
>>>>
>>>> foreach(\array_keys($arr) as $key) {
>>>>
>>>> and quietly transform that into:
>>>>
>>>> foreach ($arr as $key =>
>>>> $_unusedVariableNameThatIsntEvenSpilledToTheScope)
>>>> {
>>>>
>>>> I would be more likely to write:
>>>> $keys = array_keys($arr);
>>>> foreach($keys as $key){
>>>> Which would prevent me from being able to take advantage of the
>>>> optimization.
>>>>
>>>> So, what I was wondering, is if there are other optimizations I might be
>>>> missing out on, and if so, are they documented anywhere?
>>>>
>>>>
>>>> --
>>>> Chase Peeler
>>>> chasepee...@gmail.com
>>>>
>>>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Compiler Optimizations
I wasn't proposing that my example be supported. I'm totally okay with the
fact that it doesn't. My question was about whether or not those kinds of
optimizations are documented anywhere so that developers can make sure they
don't miss out on them by not fitting the proper pattern.
On Tue, Sep 15, 2020 at 9:40 AM Benas IML wrote:
> Hey,
>
> During my free time, I'm implementing that specific `array_keys`
> optimization. I'm not planning on supporting cases like yours (i. e.
> indirection through a variable) since there's no point in doing that. And
> also, it's not feasible to support every use case. Should we also support
> cases like this?
>
> ```php
> $a = 'array_keys';
> $b = $a(...);
> $c = 'b';
>
> foreach ($$c as $key) {
> ...
> }
> ```
>
> Obviously not. `\array_keys` optimization will work the same way as an
> optimized `strlen` function works.
>
> That means that the optimization is only going to be applied if the
> `array_keys` function is used directly in the `foreach` loop and only if a)
> either the namespace is global b) or `\array_keys(...)`/`use function
> array_keys` is used.
>
>
> Best regards,
> Benas
>
> On Tue, Sep 15, 2020, 4:23 PM Chase Peeler wrote:
>
>> I brought this up on another thread, but it wasn't addressed (which is
>> fine, since it was somewhat off-topic). I thought it might be
>> worth bringing up in its own thread, though.
>>
>> In the other thread, someone had mentioned the following compiler
>> optimization
>>
>> foreach(\array_keys($arr) as $key) {
>>
>> and quietly transform that into:
>>
>> foreach ($arr as $key =>
>> $_unusedVariableNameThatIsntEvenSpilledToTheScope)
>> {
>>
>> I would be more likely to write:
>> $keys = array_keys($arr);
>> foreach($keys as $key){
>> Which would prevent me from being able to take advantage of the
>> optimization.
>>
>> So, what I was wondering, is if there are other optimizations I might be
>> missing out on, and if so, are they documented anywhere?
>>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
--
Chase Peeler
chasepee...@gmail.com
[PHP-DEV] Compiler Optimizations
I brought this up on another thread, but it wasn't addressed (which is
fine, since it was somewhat off-topic). I thought it might be
worth bringing up in its own thread, though.
In the other thread, someone had mentioned the following compiler
optimization
foreach(\array_keys($arr) as $key) {
and quietly transform that into:
foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
{
I would be more likely to write:
$keys = array_keys($arr);
foreach($keys as $key){
Which would prevent me from being able to take advantage of the
optimization.
So, what I was wondering, is if there are other optimizations I might be
missing out on, and if so, are they documented anywhere?
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
On Thu, Sep 3, 2020 at 12:05 PM Sara Golemon wrote:
> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues
> wrote:
>
> > Do you think that it could be proxied? I mean, optimize foreach
> > (array_keys()...) syntax to not call array_keys() in fact, but a
> optimized
> > version of foreach to handle key only. I don't know it opcache could do
> > that, and if it already does.
> >
> >
> I wouldn't use the word "proxied", but yes. In my mind the compiler would
> see:
>
> foreach(\array_keys($arr) as $key) {
>
> and quietly transform that into:
>
> foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
> {
>
>
Are there other instances where we have optimizations like this? If so, are
they documented?
In terms of readability, I'm more likely to do
$keys = array_keys($array);
foreach($keys as $key){
That would obviously break the optimization we're talking about though.
Which makes me wonder if there are other places like that.
> Thus not iterating the array twice and creating a temporary array of key
> names.
>
> -Sara
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
On Wed, Sep 2, 2020 at 1:13 PM Nikita Popov wrote:
> On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel wrote:
>
> > This is a new thread for John Bafford's RFC which he mentioned on another
> > thread, see below:
> >
> > https://wiki.php.net/rfc/foreach_void <
> > https://wiki.php.net/rfc/foreach_void>
> >
>
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
>
> foreach ($iterable as $key => $_) { ... }
>
> Introducing special syntax for this has costs, both in terms of language
> complexity and in terms of implementation complexity. For example,
> implementing this feature will make foreach (whether or not the value is
> ignored) marginally slower, because we will have to explicitly distinguish
> this case. (Or alternatively, we'd have to specialize and increase VM code
> size -- it's not free in any case.)
>
>
There were two justifications given in the RFC. The first was that $key =>
$value and ignoring the value has performance costs. You indicate there
would be a cost to dealing with a special character there in order to know
whether or not to ignore the value. So, I think the question is which one
causes the bigger performance hit.
The other justification was semantic. I don't personally find that
justification for the change, especially if we could actually be looking at
performance implications.
> Iterating over just the keys is not a super common pattern and we already
> have a reasonable way to do it (that is imho just as clear, and actually
> more concise than the proposed "null" variant). The only potential
> advantage to a dedicated syntax that I see is that there could be iterators
> that can cheaply produce keys, but have expensive to produce values. That
> seems like an edge case of an edge case though, and is a situation where
> manually calling ->key() would be justifiable.
>
> Regards,
> Nikita
>
> > On Aug 31, 2020, at 5:50 PM, John Bafford wrote:
> > >
> > > Hi Riikka,
> > >
> > >> On Aug 31, 2020, at 14:13, Riikka Kalliomäki <
> > riikka.kalliom...@riimu.net> wrote:
> > >>
> > >> A common pattern that I've seen that could dearly use PHP internal
> > >> optimization, if possible, would be:
> > >>
> > >> foreach (array_keys($array) as $key) {
> > >> }
> > >
> > > I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch (
> > https://github.com/jbafford/php-src/tree/foreachvoid against php 7.0, I
> > think) that helps with this, by allowing the following syntax:
> > >
> > > foreach($iterable as $key => void) { ... }
> > >
> > > This would iterate over the keys of the iterable, and does not retrieve
> > the values at all.
> > >
> > > In theory, this should be a general performance win any time one needs
> > to iterate over only the keys of an iterable, because it does not require
> > the use of an O(n) iteration and building of the array that array_keys()
> > would, plus it works on non-array types (such as generators or
> iterators).
> > It also is more performant than foreach($iterable as $key => $_) {},
> > because it omits the opcode that instructs the engine to retrieve the
> > value. (Presumably, a future direction could include using this request
> to
> > inform generators or iterators to only return keys, and not values, which
> > could further improve performance, especially if value generation is
> > expensive. But that is out of scope for this RFC.)
> > >
> > > If this is something we'd like for PHP 8.1 and there are no major
> > objections to the idea, then after 8.0 is released, I can move the RFC
> out
> > of Draft and into Under Discussion, and presuming a vote passes, I'll
> > update the patch as necessary to work against 8.0. But my time is limited
> > and I'm not willing to put further time into the code unless an RFC vote
> > passes.
> > >
> > > Thoughts anyone?
> >
> > +1 from me.
> >
> > BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to
> > update that?
> >
> > -Mike
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
On Wed, Sep 2, 2020 at 9:16 AM Josh Bruce wrote:
>
> > On Sep 2, 2020, at 6:27 AM, Dik Takken wrote:
> >
> > On 02-09-2020 12:48, Olle Härstedt wrote:
> >> An alternative syntax would be
> >>
> >>foreach($iterable as $key => _) { ... }
> >>
> >> Using underscore as a way to signal "I don't care about this value".
> >> Same could be possible with list destructoring, like
> >>
> >>[_, _, $something] = foo();
> >>
>
> Swift also uses the underscore in places.
>
> >> 1. It is currently a valid constant name (BC break)
>
> I can name a constant an underscore??
>
> Does anyone actually do this??
>
> I guess I’m asking how impactful the break would be considering most magic
> things start with double underscore and I haven’t seen many people using
> the single underscore to represent instance variables anymore.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Isn't the underscore an alias for gettext()?
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] array_reject() as counterpart of array_filter()
On Mon, Aug 31, 2020 at 9:52 AM Josh Bruce wrote:
> Just to confirm
>
> array_filter(“!is_int”, $collection)
>
> Would result in a collection of only non-integers??
>
>
No, you'd have to put it in a closure
The original poster had a typo, I think, and meant array_reject not
array_reverse. He basically implemented the solution that Larry was
referring to, before Larry referred to it.
function array_reject(Callable $c, Array $a){
return array_filter(fn($item) => !$c($i), $a);
}
$non_ints = array_reject('is_int',[1,2,'a',3.5]);
If you don't want to write your own array_reject method, and just handle it
case-by-case, then it's still trivial
$non_ints = array_filter(fn($i) => !is_int($i), [1,2,'a',3.5]);
I do think there’s something to be said for the communication of intent
> without syntax.
>
> array_without or array_reject reads easier to me than making sure to watch
> for the bang.
>
>
I agree with Larry that userland implementation is trivial enough that it
doesn't really need to be implemented in core. It's just syntactic sugar
that's probably more trouble than it's worth. That being said, I'm by far
an expert when it comes to core, so I can't really say 1.) what performance
benefits it would provide or 2.) how hard (or easy) it would be to
implement.
> Cheers,
> Josh
>
> >> On Aug 30, 2020, at 6:55 PM, Larry Garfield
> wrote:
> >>
> >> On Sun, Aug 30, 2020, at 9:38 AM, David Rodrigues wrote:
> >> Currently we have array_filter(), but sometimes we need an inverse
> function
> >> like array_reject().
> >> array_reject('is_null', [ 1, 2, null, 3 ]); // [ 1, 2, 3 ]
> >> It could be easily implemented with:
> >> function array_reverse($fn, $arr) { return array_filter(fn($item) =>
> >> !$fn($item), $arr); }
> >> Anyway, I think that It should be implemented by core, once that we have
> >> array_filter().
> >
> > Any boolean function can be inverted with a simple ! in a short
> closure. I don't really see a need to do that in C.
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Re: Microsoft Support of PHP on Windows
On Fri, Jul 10, 2020 at 12:32 PM Jan Ehrhardt wrote: > ? Good Guy ? in php.internals (Fri, 10 Jul 2020 17:16:07 +0100): > >On 10/07/2020 17:01, Jan Ehrhardt wrote: > >> I am building PHP for Windows myself, but I know from the questions I am > >> getting that a lot of corporate customers of Microsoft are running PHP > >> on Windows Server 2016 or 2019. They are only allowed to use the > >> official binaries that are supplied on windows.php.net or pecl.php.net. > >> These corporate customers surely will not be amused by dropping > >> Microsoft's support for PHP 8. > > > >Have you thought of uploading your binaries on php.net AFTER Microsoft > >has quit the php support? Windows binaries were very useful for > >developing websites on windows system which is still the dominant > >operating system though, web developers will adapt the workload on > >ubuntu and Mint. I still use Windows and I regularly download Apache > >from apachelounge and php from the official website. > > No. And I will not do that, because I do not want to be liable for any > consequences of using my builds. I am providing them AS IS through links > on Apachelounge: https://www.apachelounge.com/viewforum.php?f=6 > > Many extensions I am building from git head, not from the official > releases by the extension developers. Sometimes I have to patch them a > little to get them building. The Solr extension for instance does not > build yet for PHP 7.4. > > >> Besides that, SMB customers are often using Microsoft Azure for their > >> Windows Server needs. Windows Azure will loose a lot of selling points > >> without supported PHP binaries. A quick search on Azure marketplace > >> revealed as well that some Azure partners will also be left in the cold: > >> > https://azuremarketplace.microsoft.com/en-us/marketplace/apps?search=windows+php > >> Are the Azure Sales people already informed about your decision? > > > >I suspect Microsoft wants to market its own product called Blazor > ><https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor> > > Microsoft's future is in services like Azure. Development tools are much > less important. > -- > Jan > > I work on an app that is almost 20 years old. It has always been hosted on windows and a lot of the early development (which is still at the core of the app) was very windows specific. Since this is an internal app used by our company, and not something that is redistributed, the fact that it was not OS agnostic wasn't an issue. With the development plans we have over the next few years for our app, we don't have the luxury of being able to devote time to making it run on a linux host. I'm OK if Microsoft decides to not officially support it, but, I'm hoping something can be done to make sure builds are still produced. I can (and have) built PHP myself on windows. That actually isn't that hard. What makes the official builds valuable is the inclusion of PGO. My other fear is that if official support for windows is dropped, PHP itself will no longer be developed with windows in mind. One reason building it is pretty easy is because it was developed to be built on Windows. If that stops happening, then building it myself, with or without PGO, will become pretty much impossible as well. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList
On Wed, Jun 17, 2020 at 5:46 AM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Lester, > > wt., 16 cze 2020 o 15:55 Lester Caine napisał(a): > > > On 16/06/2020 13:14, Michał Brzuchalski wrote: > > > I'd like to start a discussion period for my RFC which proposes to > change > > > the use of "blacklist" in Opcache configuration with better > > > self-descriptive terminology. > > > > Since there will be a higher level change to all these terms - in all > > likelihood - trying to push yet another term that does not match the > > current discussions elsewhere seems somewhat premature. The NEXT RFC > > will be to bring this in line with the 'new' industrial standard, so is > > there any point jumping the gun before the international debate has > > finished? "blocklist", "banlist", and others all have appropriate > > application but like "excludelist", they all imply a narrower usage area > > while "blacklist" is accepted generally across all applications. > > > > What ever alternative to "blacklist" is adopted elsewhere is going to > > cause confusion and adding to that confusion with a different > > 'translation' just makes the situation worse? > > > > Isn't that the more narrow term is used it's easier to understand? > We can easily vote on the right name. > > I chose the "exclude list" cause the INI setting which changes name in this > proposal > is a glob path to filenames. > Please stop using the term "glob." As a person that is above what many would consider an ideal weight, I've been called a "useless glob" on multiple occasions. This term is harmful to me as a result. > These files are then parsed as a list of glob paths for later file > exclusion on opcache run. > Another term in my mind is "ignore list" which then suggest a list of files > ignored by opcache run. > > When I grew up, I was often ignored by other people, causing me to be lonely and depressed. The term "ignore list" triggers those same feelings, so please avoid using this in the future. > Regarding the "blocklist" I have to admit that it was my first thought but > after thinking IMO it's inappropriate. > My father often called me an "ignorant blockhead" so the term "blocklist" triggers negative emotions as well. > There is nothing in the opcache what blocks files from being cached and > optimised, > they by themselves are not trying to be cached, cause the flow is from > opcache extension. > > For me to whom English is not a native language first association is with > blocking service access to the clients > which interacts with the service and try to get access to it. > That's why I think it's inappropriate here and I've changed it in the > original patch. > > The same goes for the "banlist" for me my first association is with the > client who had access to the service > but due to some policy reasons (like fo reg. destructive intentions or > overuse), the client lost access rights and > get's banned with assignnment to the "banlist". > > Therefore IMO we should choose a new name wisely so it can be > self-descriptive. > What I can propose is update of RFC with a note regarding the second vote > for the right name. > I'd like to put there an "exclude_list" and "ignore_list", but if my > reasoning about not debating > on the "banlist" and/or "blocklist" is not enough then please let me know > then I can add those two also. > > Cheers, > Michał Marcin Brzuchalski > None of the above are actually true (except for the fact that I'm overweight). The point I'm trying to raise is that context matters, and changing terms because some people refuse to understand the context is not justified. Otherwise you open a pandora's box where you either have to change everything that someone claims offends them, or, you have to pick and choose which people or group are allowed to be offended and which are not. If the term blacklist had racist origins, the discussion might be different. However, it does not, just like glob does not have origin in fat-shaming. I have no problem changing these terms if they are changed industry wise and the new terms are needed to keep up with industry standards. I might not agree with why they were changed in other arenas, but, at the point new terms become standard, the reason they became standard doesn't really matter. So, as others have said, this and other discussions about renaming terms because some might find them offensive is not something we should be doing. Renaming terms in order to align with changes to industry standards, while something we should do, is premature at this point as those standards have yet to change. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList
On Tue, Jun 16, 2020 at 9:55 AM Lester Caine wrote: > On 16/06/2020 13:14, Michał Brzuchalski wrote: > > I'd like to start a discussion period for my RFC which proposes to change > > the use of "blacklist" in Opcache configuration with better > > self-descriptive terminology. > > Since there will be a higher level change to all these terms - in all > likelihood - trying to push yet another term that does not match the > current discussions elsewhere seems somewhat premature. The NEXT RFC > will be to bring this in line with the 'new' industrial standard, so is > there any point jumping the gun before the international debate has > finished? "blocklist", "banlist", and others all have appropriate > application but like "excludelist", they all imply a narrower usage area > while "blacklist" is accepted generally across all applications. > > What ever alternative to "blacklist" is adopted elsewhere is going to > cause confusion and adding to that confusion with a different > 'translation' just makes the situation worse? > > I agree with this 100%. Without offering an opinion on whether or not we should change it, I do think it makes sense that if we do change it, we at least wait until a more standard term has been decided among other developers and projects. It would also provide another justification for the change, if the change was being made to align with industry standards. I also want to point out my agreement with others that have posted about the current climate not being conducive to an honest conversation on this topic. The current climate in the US is such that often it's not enough to agree on what the end goal should be. If someone doesn't agree with how we reach that goal and why we should reach it, they are treated as if they are against achieving the goal altogether. This topic is very susceptible to those kinds of reactions. > -- > Lester Caine - G8HFL > - > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Wed, Jun 10, 2020 at 4:33 PM Ryan Jentzsch wrote: > OMG the trolling continues even today with this nonsense. Disappointing. > Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why:: > "People don’t ask for the other parse errors even half as often as they as > for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to > them, so it looks unlikely to be a common thing you can Google, nor it > gives something recognizable to start with [sic] Yes, we all acknowledge > it’s an easter egg joke that refers to the creators of PHP. But that > particular joke has outworn its welcome in the community after repeatedly > CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine) > > I agree that it isn't the biggest issue in the world. If we had to give up one of the more impactful changes in order to implement this, it would be a different story. But that's not the case. There is no trade off here. The RFC even contains the updates required, so it's not going to take up anyone's time that could be spent on other features. > "It's a minor change and an annoyance to a lot of people. Yes, by not > changing this you’re annoying thousands of people." -Alexander Schrijver > > "It’s the same argument everyone else is giving, and really it all comes > down to this.: > Nostalgia is valued over clarity and consistency. Do you guys REALLY want > to claim that?" -Chad Minick > > "...yes, it is broken, people have to Google or ask around for a very > unclear error message when for the most part errors are (and should be) > self explanatory > ...Two things are broken: Either the token is named badly, or the token > names shouldn’t show up in error messages at all and be replaced with > something a bit more friendly. > ...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on > LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick > > Honestly, I'm not a big fan of the following argument: "However, PHP is for most people their first programming language and therefore may not have the instinct to do an online search and will end up frustrated." - Googling is such a core skill for programming, that if they can't figure that out, they don't need to be programming. However, that being said, I don't think that argument is even needed to justify this RFC anyway. The only place this MIGHT cause an issue is unit tests that are looking for that specific string. While I'm not a fan of the "just use find/replace" to update things argument, I think that's a perfectly valid one here, given the uniqueness of the string being changed. > Once again I plead for logic and sanity. At least have the courage to put > it to a vote. > > On Wed, Jun 10, 2020, 12:28 PM Claude Pache > wrote: > > > Hi, > > > > I appreciate the effort to reduce frustration in PHP coding. > > > > However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and > > you’re done for the rest of your life. > > > > May I suggest an improvement that would be much more useful than renaming > > tokens? > > > > One parsing error that I still find dreadful after more than 10 years of > > PHP coding, is: unexpected T_CONSTANT_ENCAPSED_STRING. Although > > T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time > > that when I get such an error, it means that I’ve most probably omitted > or > > mistyped some punctuation mark somewhere. However, PHP is unable to tell > me > > where exactly is the error: it tells only the line number, and I have to > > carefully scan the entirely line to find the place. Sometimes, I resort > to > > split the offending line in several ones, so that I could get more > precise > > location info. > > > > So please, let the parser tell me not only the line of the error, but > also > > the column. Then, it doesn’t matter how the offending token is named if > you > > know where it is. > > > > —Claude > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > I have a reputation on this list for being rather conservative about changes. I'm somewhat sympathetic to the symbolic reasons for keeping it around. I don't think such reasons outweigh the benefits though. The only valid solution I would support that didn't rename the token would be if we removed that token from the error messages altogether. I think that would be more likely to cause issues, though, since there could be tests that need SOME sort of token specified. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Encountering T_PAAMAYIM_NEKUDOTAYIM is a right of passage in the PHP world. I had to deal with it, so should everyone else. :-P While it'll be bittersweet to see it go, I definitely think this would be a wise update. On Wed, Jun 10, 2020 at 12:58 PM Ryan Jentzsch wrote: > With over 25+ years of software development experience it was In 2016 I was > introduced to the world of PHP development. > One day I came across the most unusual of error messages > "T_PAAMAYIM_NEKUDOTAYIM" What the hell is this?!? > That I needed to waste my time to Google this is simply insane. At the time > I thought to myself that PHP deserved some of the hate. Then I came across > this gem: https://phil.tech/2013/t-paamayim-nekudotayim-v-sanity/ > Please for the sake of logic and sanity replace this nonsense with > T_DOUBLE_COLON > > On Wed, Jun 10, 2020, 9:14 AM G. P. B. wrote: > > > Greetings PHP internals, > > > > Kalle Sommer Nielsen and myself are proposing to rename the > > T_PAAMAYIM_NEKUDOTAYIM > > token into the already existing T_DOUBLE_COLON alias, > > T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON. > > > > The RFC is located here: > > https://wiki.php.net/rfc/rename-double-colon-token > > > > Although this token is a nod to the valuable contributions made by the > > Isrealie community we believe this token is rather confusing for > newcomers. > > Moreso, as PHP is for many people their first programming language, > > they may not have some of the habits like googling errors when > > they are stuck, which leads to a frustrating experience. > > > > As we believe PHP still has many years of existence we think it is time > > to rename this token. > > > > This is backwards compatible with PHP 7 and 5. > > This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM > > and leaves this as a future scope. > > > > As the matter on hand is a relatively straight forward yes/no vote we > > expect > > it to be held after the minimum 2 week discussion period. > > > > Best regards > > > > George Peter Banyard > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
On Wed, Apr 29, 2020 at 9:35 AM Benas IML wrote: > Hello, > > I honestly don't care what it's called, but I am seeing some arguments being used in favor of changing it that I think are invalid. > Since your project is just a single example, we still can't make such a > bold > claim that `\Attribute` is used a lot. > > As with any possible BC break, the issue isn't what we know, but what we don't know. It's the potential impact to closed source or other proprietary projects out there, weighed against the benefit. Since "Attribute" is a pretty common term in programming, the odds of some of those projects having an Attribute class in the global namespace is higher than some esoteric term rarely used in a programming context. > While "attribute" is a fairly generic word, just about everyone uses > namespaced > classes and therefore it's not a huge problem. Moreover, PHP 8 is a major > release so BC in such cases isn't the first priority. > > Again, your assumption that just about everyone uses namespaced classes doesn't take into account closed source projects. I don't care if it's a major release or not - BC breaks should always be avoided without a major benefit > Also, it's important to mention that the introduction of functions such as > `str_contains()` is also a breaking change for some. But the benefits it > provides outweigh the 0.1% who may get BC issues. > > str_contains adds functionality to PHP. We aren't debating whether to add attribute functionality to PHP, but what to call it. As such, this argument is an invalid comparison. > Best regards, > Benas Seliuginas > I don't think PhpAttribute is a bad name. Per the RFC: "Attributes as a form of structured, syntactic metadata to declarations of classes, properties, functions, methods, parameters and constants. Attributes allow to define configuration directives directly embedded with the declaration of that code." - In other words, they are Attributes of PHP constructs. While that additional Php might not be necessary to avoid ambiguation in the same way it was for Token, I don't think it's an improper disambiguation either. As Derick said below "PHP owns the top-level namespace but tries to find decent descriptive names and avoid any obvious clashes." - These seems like a prime example of using "descriptive names" to "avoid any obvious clashes" As I said above, I'm ambivalent about this particular issue. However, I get nervous when I start to see the "Who cares if it breaks stuff" or "Well, they shouldn't be doing it that way, so screw them" arguments pop up. While the chances of a BC break might be minimal using "Attribute" - I don't think that PhpAttribute is an undue burden in an attempt to avoid such instances, nor is it logically inconsistent with other Php* named classes. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Understanding RFC attitudes
On Fri, Apr 3, 2020 at 12:38 PM Dan Ackroyd wrote: > Hello Internals, > > The trade-offs that are good for a project like core PHP are quite > different from the trade-offs from other projects. > > People are sometimes quite surprised by the attitude other people have > on how best to maintain and improve PHP. > > I'm hoping that documenting my understanding of the attitudes that > have been taken during RFC discussions, might avoid some of the > surprise factor in discussions and so make the conversations be less > confrontational. > > https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md > > To be clear, this is only meant to help people understand other > people's view-points. It is not a fixed set of attitudes that I think > either are or should be followed. > > It's also not aimed at making everyone agree on all topics, but just > to help set people's expectations on how any particular RFC might be > received. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I think this is a good idea. It appears to be a fair overview of various topics. Personally, instead of organizing it into the two main areas that you did, I think it would be better to maybe just list the various types of arguments used for/against RFCs, and what the pro/con positions are. As it is currently written, anything in the "less likely to pass" section might be taken as something that should be avoided - even in cases where such things do make sense. If, instead, we lay it out as "If you propose this, these are the arguments you're going to get as objections, and here are some of the justifications that have been used so far" someone might better be able to determine if their RFC for such a topic is justifiable, and if so, preempt some of the objections. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays
On Mon, Mar 30, 2020 at 1:32 PM Sara Golemon wrote: > On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel > wrote: > > > If "they" don't care about syntax, then why do you? > > > > > > Sorry I was unclear. I was reacting to the argument about broken tests in > > php-src. > > I meant: they don't have *expectations* about the syntax, but they'll > most > > likely want to be able to read it. > > > > And we circle back to the current syntax being perfectly readable. We > could keep this up all quarantine... > > In a more practical example, > https://github.com/php/web-php/blob/master/include/releases.inc is an > example of a var_export() generated file that lives in the wild and is > regularly updated. > > I would say it's fairly readable, HOWEVER I WOULD AGREE WITH YOU that it > would be MORE readable using short array syntax and skipping the index > numbers. In fact, I had exactly this thought nearly 3 years ago when I > started touching this file regularly. (plus the fact that the structure of > this array is kinda gross). > > You'll note though, that I'm not championing making this file more > reasonable. Because it doesn't matter. Because accidental damage to > existing code isn't worth a minor bit of aesthetics by a file which is > primarily read by machines. If it really mattered to me in any meaningful > way, I'd write the dozen or so lines of script needed to output in a > "pretty" way. Or I'd go google and find brick/varexporter. > > Lastly, there are at least six RMs at any given moment working on PHP's > release. Can you imagine if we were updating this file using different > versions? The git churn would be horrific. Do not want. If we really > wanted "pretty var_export", then there'd be no real choice BUT to use a > library script to do the serializing. > > -Sara > I'm with Sara on this, which shouldn't be a big surprise. Just out of curiosity, is there any reason we couldn't add an optional parameter called "$short_array" or whatever that defaults to false? Then there shouldn't be any backwards compatibility issues. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Constructor Property Promotion
On Thu, Mar 26, 2020 at 9:33 AM Paul M. Jones wrote:
>
>
> > On Mar 26, 2020, at 08:30, Nikita Popov wrote:
> >
> > Hi internals,
> >
> > I would like to submit the following RFC for your consideration:
> > https://wiki.php.net/rfc/constructor_promotion
>
> Big fan. Thanks for this.
>
>
I like this too. One question (and apologies if I overlooked this in the
RFC), but is type-hinting required, or would the following be accepted:
class bar {
public function __construct(public $foo){}
}
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC]
On Tue, Feb 11, 2020 at 8:19 AM Nikita Popov wrote:
> On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga
> wrote:
>
> > On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
> > wrote:
> > >
> > >
> > >
> > > Le mar. 11 févr. 2020 à 12:52, Diogo Galvao a
> écrit
> > :
> > >>
> > >> On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga
> > wrote:
> > >> >
> > >> > Hi internals,
> > >> > I Would like to present a possible new "::func resolution" for your
> > >> > consideration.
> > >> ...
> > >> > use function \My\I18N\i18n_translate;
> > >> >
> > >> > $mapped_array = array_map(i18n_translate::func, $array);
> > >> ...
> > >> > What is your opinion ? Do you see it useful ?
> > >>
> > >> I've wished for this on many occasions and think it'd be really
> useful,
> > as long
> > >> as it could work with methods as well:
> > >>
> > >> $mapped_array = array_map(I18N::translate::function, $array);
> > >>
> > >> For what it's worth I guess it could just return [I18N::class,
> > 'translate'].
> > >
> > >
> > > I wish this would return a Closure instead, making $foo::function the
> > equivalent of Closure::fromCallable($foo).
> >
> > Hi, Nicolas,
> >
> > Currently, when ::class is used, class with
> > can or cannot exists in that moment.
> > Using ::func( or ::function ), I think
> > should keep the same behavior.
> >
> > Using ::func as alias of "Closure::fromCallable" check if function
> > exists in that moment. It is certainly useful, but, I think it's more
> > important be consistent
> >
>
> Checking whether the function exists is really unavoidable for functions,
> because you don't know whether
>
> namespace Foo;
> var_dump(strlen::function);
>
> refers to 'Foo\strlen' or 'strlen', without first trying to look up the
> former.
>
> I agree with Nicolas that this kind of feature would provide the most value
> if it created a Closure. This would circumvent all the issues outlined in
> https://wiki.php.net/rfc/consistent_callables.
>
> Regards,
> Nikita
>
Can anyone thing of a use-case where you would want a string name of a
function and a callable would not be acceptable, besides possibly debugging
code that said 'echo "I'm calling ".myfunction::function;'? Everything that
I can think of that accepts a function name, also accepts a callable (e.g.
array_map), but I could be forgetting something.
If not, then I think it makes sense to return a callable. It might not be
entirely consistent with the behavior of ::class, but, a class isn't
entirely consistent with a method/function either, so I think there is some
latitude for small differences.
As for the ::func vs ::function. I think ::function is safer, since it's a
reserved word. Otherwise you might run into issues with something like this:
class foo {
const func = "bar";
}
function foo(){}
echo foo::func;
Probably not something that happens very often, but, I think the 4 extra
characters to prevent it would be worth it.
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Re: [RFC] deprecate md5_file and sha1_file
On Mon, Feb 10, 2020 at 5:36 PM Mark Randall wrote: > On 10/02/2020 21:49, Tom Van Looy via internals wrote: > > I suggest to deprecated the functions md5_file() and sha1_file(). This > will > > make people think about upgrading to a better alternative. > > It won't. > > At best it will make people switch to the hash function. At worst people > will not upgrade. > > If people are using the existing md5 / sha1 algorithms, chances are it's > because they're actually wanting to get a hash to compare to something > that has already been stored. > > There's not much point in deprecating the algorithm if we don't > eventually plan to remove it, and there is an exactly zero percent > chance of it being removed at any point in the next 50 years. > > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Why? What does deprecating those two functions do to make PHP a better language? It doesn't add any new features. It doesn't fix any security issues. It doesn't even take away the ability to perform the functionality that they provide, since it still exists in the hash_file function. If you don't like the function, then don't use it. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Operator overloading for userspace objects
On Fri, Jan 31, 2020 at 10:55 AM Ben Ramsey wrote:
> > Also, I want to reiterate: Any of these operations MUST be designed to
> return a new value, never modify in place. These operators only make sense
> on value objects, not service objects, and value objects should be
> immutable.
>
> I completely agree. This was the gist of my earlier comments.
>
> Maybe we should resurrect discussion of the immutable classes and
> properties RFC: https://wiki.php.net/rfc/immutability
>
> If we add the ability to specify immutability, then we can enforce in the
> engine that the left and right operands must be immutable.
>
> For example:
>
> public function __add(immutable $left, immutable $right);
>
> Cheers,
> Ben
>
>
Ideally, I don't think the items have to be immutable. Here is a silly
use-case:
public function __add($left,$right){
$left->operatedOn++;
$right->operatedOn++;
return $left->value + $right->value;
}
However, given the nature of operator overloading, I think the users should
EXPECT what they pass in will not be changed, unless they explicitly pass
by reference. This means we'd have to "change the rules" for operator
overloading magic methods, where objects are passed by value unless
explicitly passed by reference ( public function __add(&$left, &$right) ).
I think that is an even worse idea!
So, I think you really have two options. Change the rules so that even
objects are passed by value in this specific circumstance, and there is no
ability to pass by reference. I still don't like this, because it changes
the rules for only a specific scenario, but I think it's a better option
than the one above, as well as a better option than allowing mutable
objects 100% of the time - although, I'm not totally against spelling out
in the documentation "Don't modify the items passed in or you'll get
unexpected results!"
The other options is the immutability RFC. This doesn't change the rules -
it just adds a new rule. I don't see in that RFC, though, anything about
the immutable type hints. That's really the only thing that I think is
applicable to operator overloading.
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC - discussion] __toArray()
On Tue, Feb 4, 2020 at 11:04 AM Steven Wade wrote:
>
> > Sorry if it's been said in the discussion so far, but I do not see why
> > `print_r` should convert anything to an array. It accepts multiple
> > kinds of types including strings, numbers, and so on, and I think
> > adding this behavior to `print_r` is a different thing than wanting a
> > standard way for objects to be converted into arrays.
>
> You’re right, that’s my bad. I swore I tested print_r() with a class and
> __toString() and it cast it, but I just ran it again and it just outputs
> the object. The goal would be to have __toArray() behave on arrays like
> __toString() does on strings. I’ll update the RFC to remove the reference
> to print_r(). Thanks!
>
>
> > And on that note, what is the motivation for wanting a magic method
> > for converting an object into an array? Why not make it an explicit
> > operation? I do not see the point of the magic here, except _maybe_
> > for adding it to `ArrayObject` or something to allow it to work with
> > the array_* functions that work without references, in which case I
> > think we think this RFC is the wrong approach as it is inadequate for
> > that purpose.
>
> I think the motivation is exactly what you said. Allowing developers more
control over how the object is treated when casted to an array - which
would include when it is passed into an array_* function.
Here is a use-case:
if(is_object($arrayOrObject)){
$a = array_map($callback,$arrayOrObject->toArray());
} else {
$a = array_map($callback,$arrayOrObject);
}
becomes
$a = array_map($callback,$arrayOrObject);
I'm not making an argument one way or the other for whether the above is
justification, but, it does at least allow the above simplification of code.
> PHP’s pretty magical already, so adding another magic method isn’t out of
> the question and would keep things inline with how some things are done
> already. The idea for having magical casting is to make it simpler in the
> user land for general array behavior when reading or looping.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] [RFC - discussion] __toArray()
On Tue, Feb 4, 2020 at 9:23 AM Marco Pivetta wrote:
> On Tue, Feb 4, 2020, 14:50 Aimeos | Norbert Sendetzky
> wrote:
>
> > Am 04.02.20 um 14:43 schrieb Marco Pivetta:
> > >> I think we can't classify it as BC break, because no existing code
> > >> implements __toArray at the moment, and hence it will not fail when
> this
> > >> feature is introduced and code gets upgraded to newer versions.
> > >
> > > It is a BC break because it changes the semantic of `(array) $object`:
> > the
> > > operation is no longer stable between two versions of the language.
> >
> > It wouldn't be a BC breaking change if `(array) $object` works like
> > before when __toArray() isn't implemented by an object. As nobody should
> > have implemented __toArray() because it's a reserved name for magic
> > methods, we should be fine.
> >
>
> The operation in question, when seen by its signature, is:
>
> (array) :: object FieldTypes -> Map String FieldTypes
>
> The proposed RFC changes this to (pardon the weird union type: my type-fu
> is not that advanced):
>
> (array) :: (FieldTypes|IO ToArrayTypes a) => object a -> Map String a
>
> This changes the return type of a very much pure function (even makes it
> non-pure: fun), and is a very, very, very clear BC break.
>
> >
>
I think we all know that I'm very big on avoiding BC breaks. I personally
don't see this as a BC break, though. At least not one with PHP.
Right now, behavior when casting things to an array is like so:
(array)$scalar ==> [$scalar]
(array)$array ==> $array
(array)$object ==> [$prop1=>$val1, $prop2=>$val2, ...]
So, assuming that right now I have the code:
$x = new SomeThirdPartyArrayLikeObject();
//stuff
$y = (array)$x;
//$y ==> [$prop1=>$val1, $prop2 => $val2, ...]
In a future version, in order to make that library more array-like, the
following is added:
public function __toArray(){
return [$this];
}
Based on that, I'd argue that the BC break is with the library, not PHP. If
the __toArray function is not implemented on that class, then nothing
changes. The only way you'd get BC breaks with PHP itself is if core (and,
arguably extension) classes started behaving differently when cast to an
array.
I'm personally in favor of anything that is going to allow us to create
array-like objects that can be treated like arrays. I personally hate
having to write:
if(is_object($var)){
$x = [$var];
} else {
$x = (array)$var;
}
No, the other question is whether we do it with a magic method, like
__toArray() or an interface. I personally like magic methods, but, in the
end I'm ambivalent on that.
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Inline switch as alternative to nested inline conditional
On Wed, Oct 16, 2019 at 4:37 AM Kosit Supanyo
wrote:
> I mean separation between cases not case conditions. Examples in your RFC
> uses semicolon as case separator instead of comma.
>
> $say = switch (date("w")) {
> case 0 => "weekend!";
> case 1, 2, 3, 4, 5 => "weekday :(";
> case 6 => "weekend!";
> };
> echo "Today is {$say}";
>
> I prefer comma because semicolon should only be used to separate statements
> but switch expression is list of condition/expression pairs not statements.
> So it should be:
>
> $say = switch (date("w")) {
> case 0 => "weekend!",
> case 1, 2, 3, 4, 5 => "weekday :(",
> case 6 => "weekend!",
> };
> echo "Today is {$say}";
>
>
While using colons and semicolons would better sync up with current switch
syntax, I definitely like using arrows and commas better.
My only issue* is the fact that this introduces multiple ways to do the
same thing, which I thought was confusing and bad for new developers
*Not really an issue, just being a bit snarky. I actually love proposals
like this. It adds something useful to the language, people that don't like
it don't have to use it, and the positives outweigh the negatives in terms
of BC breaks (which are none, in this case, making it really easy to
outweigh them).
You may think t's fine because Java uses semicolon but IMO Java had made a
> mistake. (C# is semantically correct)
>
> Cheers
>
> On Wed, Oct 16, 2019 at 2:54 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Hi Kosit,
> >
> > śr., 16 paź 2019 o 09:41 Kosit Supanyo
> > napisał(a):
> >
> >> Hi Michal
> >>
> >> I'had the idea similar to your RFC but instead of using `switch` keyword
> >> I think introducing `when` keyword is better. (as I know a language that
> >> uses this keyword is Kotlin)
> >>
> >> $result = when ($v) {
> >> 'foo' => 1,
> >> 'bar' => 2,
> >> 'x', 'y', 'z' => 3,
> >> default => null,
> >> };
> >>
> >> Above you can see that `when` syntax is more semantic than `switch`. And
> >> it is easier to implement in parser because it has no
> statement/expression
> >> ambiguity.
> >>
> >> But this might not be preferred by BC camps because introducing a new
> >> keyword might break BC.
> >> And if `switch` is chosen I still think the syntax should be comma
> >> separated instead of semicolon separated for consistency with other list
> >> expressions (array/function call).
> >>
> >> $result = switch ($v) {
> >> case 'foo' => 1,
> >> case 'bar' => 2,
> >> case 'x', 'y', 'x' => 3,
> >> default => null,
> >> };
> >>
> >
> > That's exactly my proposal with commas, see here:
> >
> https://wiki.php.net/rfc/switch-expression-and-statement-improvement#switch_expression_introduction
> > Unfortunately, this RFC needs more work cause it mixes switch statement
> > enhancement with comma-separated list syntax and of switch statement - I
> > need to split it into two RFC's
> >
> > This is nice hearing that this idea has an interest.
> > As soon as the RFC will be split and finished I can start a discussion
> > thread.
> >
> > Cheers,
> > Michał Brzuchalski
> >
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Internals "camps"
On Thu, Oct 10, 2019 at 1:30 PM Walter Parker wrote: > > > > > > No. The compromise is funding a ferry system. Or laying Internet between > > them. Or a passenger pigeon mail route. > > > > Sometimes compromise requires deep discussion about the motivations for > > each side and coming to a lateral, mutually acceptable, solution. > > > > But we'd rather not discuss motivations and just bicker about the surface > > results. I.e., argue the X, rather than the Y, of these little XY > problems > > we're solving. > > > > > > > Build a ferry system is alternative to building bridge. I can see that as a > compromise, I can also see that as a separate project created to serve > demand after the the bridge project is rejected. Where a ferry system is > started because there is still demand for transit, just not enough demand > to pay for a bridge. > > With respect to the backtick proposal, what is the "ferry" project? Do we > have to come up with one before we can cancel the "bridge" project or can > we cancel the "bridge" project on its own merits and then discuss a future > project that solves the actual underlying problem? > > "Ferry" projects might be: more/better training on PHP, better > documentation so that the backtick is no longer an "obscure" feature to > those that don't have a shell/Unix/Perl background, tooling to warn people > when they misuse this feature. > > > To the side that says "There is absolutely no reason we need to go to, or communicate with, the island in the first place," a ferry project isn't a compromise. The position of the "anti-bridge" builders isn't because they are against building bridges - it's because they are against spending resources on attempts to get to the island in the first place. The other side might have valid arguments on why we need to get to the island, but, just proposing different ways to get there isn't compromising with the side that doesn't want to go there. > Walter > > -- > The greatest dangers to liberty lurk in insidious encroachment by men of > zeal, well-meaning but without understanding. -- Justice Louis D. > Brandeis > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Constraints and userland@
On Thu, Oct 10, 2019 at 3:30 AM Benjamin Morel wrote: > > > > As a part of PHP community I like the idea. I'd propose something that > > could make the > > proposal simpler in implementation. > > Create a poll system where users are authorized to be registered and be > > able to vote if > > they are github/gitlab users with >1000 commits in projects where PHP is > > one of the main > > languages. I think something like that should be doable and will not > > require any "paper > > work". It should give quite good estimation on the community preferences > > (even if it would > > exclude non-open source entities). > > > > I do like the idea very much as well. However, if this is to be automated, > I wouldn't base the right to vote on the number of commits, but rather on > the number of GitHub stars, as it's way too easy to create artificial > commits on a new account at any time. > For example, allow any repository owner or main committer (for orgs) for a > repo with >= 100 stars. > > Or, avoid doing anything automatically, just decide on a baseline set of > requirements that can be verified automatically (like at least n commits to > public repos, or at least one public git repo with >= n stars, etc.) then > review each *passing* application manually. This way the number of > applications should be manageable, there could be a queue that all current > maintainers could have access to and take a few minutes here and there to > review. > > I've spent the last 14 years working on an internal system that is built with PHP. I've been using PHP in one form or another for the last 20 years. I've done some minor work on various open source projects, but not very much. This requirement would mean that I don't get a vote, despite my many many years of experience with the language. I've proposed something similar in the past where various groups would be able to apply for voting rights. Each group would get one delegate. The difficult part is that a committee would need to exist that would review and approve applications. This was rejected because it created a lot of additional work for a small group of people that would be required to manage those applications. I don't think there is an EASY way to allow userland voting. I think there are many ways it could be done, but all of them would require additional time and dedication from people already putting in a lot of time and dedication to the development process itself. By keeping the review process manual, we can also easily revoke someone's > voting rights if the application turned out to be fraudulent (accepted by > mistake). > > — Benjamin > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Internals "camps"
On Thu, Oct 10, 2019 at 12:11 AM Mike Schinkel wrote: > > I'm not sure where's the log jam here? > > The issue is not this specific RFC. > > As I wrote earlier, there appear to be heated and non-stop debates over > (at least) BC, and possibly other areas. People dig in on a position and > then won't consider any other options that might be available. > > > It's a logjam only if somehow we were to imagine more BC > > breaks, more deprecations and more removal of functionality is somehow > > vitally necessary for PHP - which decades of thriving without all that > > amply prove to be false. > > Let me restate then, because what was important was not that the word I > used matched internals@ circumstances exactly, but the fact that there is > an issue with how the process currently works, as many other people have > noted already. > > We can call it something other than a logjam if it is important to you > that the word matches. What about dysfunction instead? > > > I don't see what's wrong with just "do not break BC unless you > > absolutely can't avoid it"... How comes now we have to spend > > so much time at affirming the obvious? > > Frankly I would agree with that, if it were not for a large number of > people who are actively promoting changes to PHP that would break BC. So > clearly the current composition of this list includes people who see > something wrong with the approach you see no reason to question. > > Note I am not endorsing their opinion but I am recognizing they have this > opinion and they are actively trying to change PHP. So we can embrace > insanity — as Einstein would say — and fight never-ending battles on the > list, or we can find ways to accommodate everyones needs and wants, > assuming everyone else is willing to find way to accommodate the needs and > wants of people that disagree with them. > > Looking in from the outside, few people who send emails to this list > appear to be interested in finding common ground. But maybe if we help > everyone recognize that nobody wins — including themselves — when a group > of people divide up and stake out intransigent and diametrically-opposed > positions then the list can be a lot more productive. > > No single person owns PHP so it is rather ungenerous to adopt a view that > PHP should conform to any one individual view of the perfect programming > language. So what if instead we collectively ask ourselves the question > "What can I do to meet the other people half way — in ways that won't > really cost me all that much — rather than to maintain an unrelentingly > rigid posture about the needs and wants of others?" > > -Mike > > Mike - I have no issue with compromise when it makes sense. Sometimes, though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One side wants to build a 100 yard bridge to an island. The other side doesn't think we need to build the bridge because we don't need to go to the island. What's the compromise? Building a 50 yard bridge? The fact is, when there is a compromise that makes sense, people usually suggest it. One example being Zeev's proposal on the RFC to raise the error levels of undefined variables to making it opt-in. Zeev's stance on the issue was that we shouldn't do anything that was mentioned in the RFC, but, he felt that a compromise would be to at least make those changes opt-in. That proposal was rejected by pretty much everyone. That's probably why it wasn't proposed this time, either. As for this particular RFC, I think it's a pretty binary decision. Deprecate them or don't. As long as I've been involved with PHP, nothing is ever deprecated unless the eventual goal is to remove it. I could be wrong, and welcome examples where we've deprecated something where the end goal wasn't removal. Assuming I'm correct though, that provides a pretty strong reason for why we wouldn't start doing it now. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
On Tue, Oct 8, 2019 at 2:11 PM Stanislav Malyshev wrote: > Hi! > > > When evaluating the _unique_ cost of migrating legacy code, it should be > balanced with the _continual_ cost of keeping the feature. That includes: > > > > * People wondering what that strange syntax does, or, worse, mistaking > it with a variation of string literal. > > * Difficulty to search occurrences of `shell_exec`. > > * People trying to deactivate functions executing external programs > (such as `shell_exec`) using the "disable_function" ini directive, > wondering how to deactivate the backtick operator (since there is no > `disable_operator` directive). > > These are not costs, since "people wondering" does not cost anybody > anything. People are free to wonder about anything, it's not a cost on > existing users on PHP. If those people are interested in learning > something, they'd read the manual and know. If they don't, they can keep > wondering, it's not an argument for anything. > > I was going to learn c++, but then I came across these weird operators >> and <<. At first I thought they were heredoc, but, that obviously wasn't the case. My next guess is that they were some sort of strict comparison === is more strict than ==, so I figured >> is more strict than >. That wasn't the case either. After wondering for a while what it could be, I decided to look it up. It ends up that you use it to output text. cout << "Hello World"; It was SO confusing, because they also have printf which can be used to output text. I decided that c++ is obviously a garbage language and gave up. Not sure why anyone would ever use it! > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis wrote: > > -Original Message- > > From: Olumide Samson [mailto:oludons...@gmail.com] > > > > it should be deprecated for exec usage since they both do same thing > > With that logic does the same thing and is hard to find in internet search engines (was in > some other argument). > > And we should deprecate the "print" command, since it's the same as echo. We should deprecate 'printf', since you can just do 'echo sprintf' and, now that I think about it, we should deprecate sprintf as well, since you can just use vsprintf. It's a simple change too... sprintf($s,$a,$b,$c) => vsprintf($s,[$a,$b,$c]);. I'm just it can be done with just a simple regex search/replace. The fact that are SO many different ways to output text is REALLY confusing for new developers. I think it's imperative we fix all of these items RIGHT NOW. By doing so, I'm sure all the .NET developers that are talking smack about PHP will suddenly denounce c# and start using PHP as well! > > > This isn't high cost breaking changes coz it has a verifiable, ready > alternative to upgrade to without huge Regex searches. > > Since `` are used for literal strings (for poorly chosen reserved words as > field, table names (which happens from time to time)) in MySQL (multiline) > queries I doubt there is a simple way to distinguish and replace everything > to exec(). > > rr > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [VOTE] Reclassifying engine warnings
On Thu, Sep 26, 2019 at 4:31 AM Christian Schneider wrote: > Am 26.09.2019 um 09:41 schrieb Nikita Popov : > > * Remainder: 54 yes, 3 no. Accepted with 95% majority. > > Just for the record: > The one I'm most concerned about here is the foreach on undefined > variables throwing an exception. > While this was already promoted to a warning at an earlier stage it still > allowed a program to finish with a well-defined result (looping over > nothing does nothing). > Now this code will stop with an Exception and possibly won't produce its > output. > > I agree. At the very least, I'd propose that null (and ideally false) NOT throw an exception. There are enough instances of methods that return one of those values when there is no data (so, not an error situation) but an array when there is. > I noticed this before the vote but as the mailing list was already flooded > with the 'undefined variables' discussion I feared that there was no place > to bring this up without getting personally attacked like I was for the > undefined variables stuff. > > Thanks for bringing this up. I think this should be noted in relation to the other RFC currently out there. Those of us speaking out against this RFC are the ones being held up as examples of why that RFC is needed, which this statement actually shows that it was those in favor of the RFC that were behaving in a way that intimidated others and made them feel reluctant to contribute. > Anyway, the vote is done, I said my piece and will shut up about it now, > - Chris > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
I've copy/pasted Kalle's email at the bottom so that I can address points made in both emails without risking someone getting distracted from the myriad of emails relating to coordination of work on PHP. On Thu, Sep 19, 2019 at 2:11 PM Mark Randall wrote: > On 19/09/2019 18:38, Chase Peeler wrote: > > So, in other words, if the majority of core members decide they want to > > force strict typing in PHP 9, and non-core PHP developers voice their > > opposition to such a change, there would be nothing to prevent those core > > members from voting to suspend the non-core members from the list, except > > to hope that such power wouldn't abused? > > You may be misinterpreting the intent of the RFC. > > It's not the intent that I'm worried about. It's the potential application. No one ever puts a system in place and goes "I'm sure we'll abuse this, but, who cares." Everyone always assumes that their group is the exception, and they will be responsible, and will never abuse the power they were given. History has shown us that regardless of how noble the intentions were, if there is a potential for abuse, it will likely be exploited. Also, part of the intent is to prevent RFC discussions from distracting from the ability to use this list to coordinate work with PHP. If that's the case, wouldn't the better option be to create a new list for RFC discussions, and allow PHP-DEV to exist for coordinating work? I don't believe this RFC is aimed at silence productive debate, it is > clearly aimed at limiting the access of what I can only imagine is a > small number of people whose continued involvement would be severely > detrimental the proper functioning of internals. > > For example, if one person were to be responsible for between 30% to 40% > of all posts in a given high-volume day, that person would, quite > rightly, be seen as entering the realms of disruptive behaviour in light > of the existing internals guidelines regarding considerate posting, and > they may find themselves prevented from continuing those actions. > > It also has the unintended consequence of silencing people that are afraid they might be stepping over the line. The line is imaginary and entirely subjective, so, it's easy to see why. Also, non-core developers definitely feel intimidated by the core developers on this list. They feel they are not encouraged to contribute. I was talking to someone the other day that doesn't even feel comfortable voicing his agreement with certain things, lest it come back to negatively impact his ability to propose some changes he'd like to see. > Something I think most people would consider entirely reasonable. > > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > That is correct. What it seems to me like you are hinting here is that > no Core Developer is listening to the community at large feedback, > which is simply not true. > > That wasn't my hint at all. My hint was that this is a very big potential for abuse. > I do not see the latter part of your question as an issue if you got > nothing to hide. In the time the PHP project has been going, then I > think less than a handful of people have been banned from Internals, > one of them being Reindl who still keeps messaging people off list (as > you most likely remember from some of the previous debates you have > taken part of). So given that track record, along with how the project > philosophy generally is, I do not see abuse being a problem, even the > sligtest. > > In that time we also haven't put a process in place where a small number of PHP developers can vote on the ability to suspend another member. As such, it took grievous abuses to get suspended. Just because power wasn't abused in the past, doesn't mean it won't be in the future. This is especially true if you put things in place which allow those abuses to take place with an air of legitimacy around them. > If you think that not having a say by not having the right to vote, > then I advise you to contribute by code to earn it like all of us > have. > I've never complained once about the fact that I can't vote. However, I think it's all the more important that I'm able to voice my opinion because of that. Also, while contributing to PHP in order to be able to vote on changes to PHP makes sense, I don't necessarily think that contributing to PHP qualifies you to have a say in who can participate in the discussions about those changes. In the end, why should I not fear abuse of power? Dan, who wrote this RFC, ended an email yesterday with an attempt to intimidate me - noting my response and how long it took me to send it. People like to accuse Zeev of making power grabs - yet I've never seen him attempt to put something in place which could be used to actually silence his critics. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
On Thu, Sep 19, 2019 at 1:36 PM Dan Ackroyd wrote: > On Thu, 19 Sep 2019 at 18:33, Chase Peeler wrote: > > > > Would the removal votes be limited to the same people able to vote on > RFCs, > > Yes, that's correct. > > cheers > Dan > So, in other words, if the majority of core members decide they want to force strict typing in PHP 9, and non-core PHP developers voice their opposition to such a change, there would be nothing to prevent those core members from voting to suspend the non-core members from the list, except to hope that such power wouldn't abused? -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
On Thu, Sep 19, 2019 at 1:18 PM Dan Ackroyd wrote: > Hi internals, > > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit > > A couple of notes: > > * although the RFC would only be applicable to messages sent once it > might be approved, it would still be nice if people consider how their > messages affect other people before then. > > * any inappropriate messages sent privately to me have a very high > chance of being replied to on the internals list. > > * everyone should bear in mind this RFC might gain more attention from > people outside the PHP internals community than normal. > > * I think this solution isn't going to be a great one, and that it > would be better if we had a less controversial way to address > non-productive behaviour. If someone wants to start a discussion on > replacing this RFC that would be great, but as I said in the RFC in my > opinion this is a needed short term solution. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Would the removal votes be limited to the same people able to vote on RFCs, or open to all list members? -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Improving productivity of internals mailing list
eel that way towards me. I also don't think it's fair to expect people to limit the responses they make to others responses. I'm only aware of one time where I sent two responses to a single email. In all other instances I have kept it 1:1. Now, when 5 different people are making points that I feel warrant a response, that's going to lead to those people sending 1 email each while I send 5. If it's a minor issue, then I probably won't respond to each one, maybe not at all. However, if it's an issue which I think is critical, like the uninitialized variables, I'm going to be thorough in my responses. The gravity of the topic demands such behavior. That means if person A makes point A, and I respond, and later person B also makes point A, then I'm going to respond to them as well, with pretty much the same response - since they obviously didn't see my first response. > # Solution > > We should not be too timid to, very nicely, ask people to consider how > their behaviour is affecting how usable the mailing list is for PHP > core developers. > > If someone who has not contributed to PHP, ignores that feedback and > makes it difficult for us to have productive conversations on this > mailing list, then that would be a different problem than the > well-intentioned but accidental disruption people who are new to the > group are causing, and so should be handled separately. > > # Problem 4 - Senior project members aren't following our email etiquette. > > Solution: I'll post an RFC to address this. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings
On Wed, Sep 18, 2019 at 12:51 PM Nikita Popov wrote: > On Wed, Sep 18, 2019 at 6:32 PM guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > Nikita, > > > > I'd suggest to wait until the current vote ends and then open a new > > RFC to vote this one, otherwise it'll be disrupting. > > > > Err, to be clear, I'm not suggesting to change the RFC under vote. We have > enough drama without that ;) > > I certainly don't care about this enough to run it through a separate RFC > vote either. I'd like a simple consensus decision on a minor point. If > Chase & co tell me that "This is no problem for us, go ahead" or "This is > going to break all our code, leave it alone" that's good enough for me. > > I don't know if I should be flattered or concerned that I was called out by name :-) I also want to reiterate, for the record, most of my arguments in regards to breaking BC isn't "This will be hard for me" as much as it its "This will be hard for a lot of other users" - I would never ask for anything to be done based on a use-case that only applies to me. That being said, I don't really know what the impact to the rest of userland would be. Since you can't actually redefine constants, I would argue that defining a previously defined constant *IS* probably an error situation. We actually have a "local_constants.php" that's included at the top of "constants.php" file. We can then define things in the local_constants.php, "overriding" the value in the constants.php file. All of the defines in the constants.php are preceded with @ though. Not sure if @ will suppress exceptions, but if not, that can always be put in try/catch (it'll just be REALLY ugly :-)). Also, we're trying to migrate away from the constants to using YAML configuration files, which handle per-environment overriding much better, but I digress. I think that's a specific exception though, where we know that we might be trying to define an already defined constant, and don't want it redefined. In most cases, if you are defining a constant, it's because you want it defined to that value, and are not aware it already was defined. I find that a totally different situation than using $i++ without having done $i=0 first. > Context is that the current notice prevents constant propagation > optimizations. A warning won't help us either, but it would be the first > step towards making it an exception in the future, which *would* enable > those optimizations. > > So, this is a case where there is an advantage to the change beyond "We want things to be more strict" - As many of us have said, we aren't against BC breaks. We just feel they should provide something that makes the language functionally better at a level that justifies the break. > Regards, > Nikita > > > > > > On Wed, Sep 18, 2019 at 12:29 PM Nikita Popov > > wrote: > > > > > > On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov > > wrote: > > > > > > > Hi internals, > > > > > > > > I've opened the vote on //wiki.php.net/rfc/engine_warnings. > > > > > > > > There are 4 votes, all of them independent. The first 3 are for > > specific > > > > cases that were controversial during the discussion, the last one is > > for > > > > the remainder of the proposal. > > > > > > > > Voting closes 2019-09-26. > > > > > > > > Regards, > > > > Nikita > > > > > > > > > > I just realized that I missed one notice here, because it is generated > > from > > > a different location: "Constant %s already defined" (The define/const > > will > > > be ignored and the previous value used.) > > > > > > It would be great to have that as an exception for optimization > reasons, > > > but as it's only a notice right now ... what do people think about > > > promoting it to a warning? > > > > > > Nikita > > > > > > > > -- > > Guilherme Blanco > > SVP Technology at Statflo Inc. > > Mobile: +1 647 232 5599 > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Evolving PHP
On Wed, Sep 18, 2019 at 9:43 AM Claude Pache wrote: > > > > Le 16 sept. 2019 à 21:32, Nikita Popov a écrit : > > > > * Discussion threads on this mailing list have been very unpleasant > > recently. I am unwilling to actively participate in them in this form. > This > > is bad for everyone, but particularly for opponents of proposals. It > means > > that we cannot establish the necessary discourse to explore improvements > or > > alternatives. The recent propensity to suppress certain discussion topics > > entirely, as well as the use of overwhelming quantity to > disproportionately > > push a position, contribute to the unproductive discussion environment. > > > > > The discussion would have been less unpleasant if everyone sought > consensus, that is, tried to find a solution that is appropriate for > everyone, instead of trying to convince others that their opinion is the > right one. > > There is a qualitative difference between consensus and unanimity. > Unanimity means that a solution is preferred by everyone — which is > reasonably not possible. Consensus means that a solution is acceptable to > everyone, even when it is not the best one for everyone. This is mostly > possible, but only if everyone tries to satisfy not only themself, but also > the others. But consensus cannot be measured by vote. > > For example, throwing a TypeError for uninitialised variables cannot reach > consensus, because it is not appropriate for those that rely on implicitly > initialised variables. Triggering an E_WARNING is nearer to a *possible* > consensus. > > I am not optimistic that there would be a mindset change in the direction > of seeking consensus for every participating party of the discussion. > However, I am suggesting that if a RFC try to seek a solution that is *at > least* acceptable to everyone, there will be less frustration and less > irritation from the minority. > > You've hit the nail on the head. I can't speak for everyone, but I know the while both Zeev and myself did not like most* of the ideas proposed in the RFC, we both had mentioned the idea of making them opt-in as a possible compromise. That proposal was flat out rejected. At the same time, we do have to be realistic and realize that sometimes a compromise solution isn't feasible or the way to go. If one side wants to build a 100 yard bridge to an island, and the other side doesn't want to build the bridge at all, compromising and building a 50 yard bridge isn't a good solution. * I say most, because there are a few things that we were OK with - which goes back to something else Zeev mentioned, which is not putting so many changes into a single RFC and/or a separate vote for each proposed change. I personally favor limiting the number of changes in an RFC because I think it's hard to focus the discussion, even if the votes are separated out. > —Claude -- Chase Peeler chasepee...@gmail.com
