Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
Hi Sara
Den tors. 15. feb. 2024 kl. 21.08 skrev Sara Golemon :
> * Better typing for setOpt() methods.
> Comment: Yep, this is a good and fair point. It's going to take a little
> more dicing up of the current implementation, but hopefully not too rough.
> Proposal: Keep untyped setOption() method (1/ Easier migration of existing
> code, 2/ Some options may prove difficult to type), but add:
> * CurlHandle::setOptionBool(int $option, bool $value): CurlHandle
> * CurlHandle::setOptionInt(int $option, int $value): CurlHandle
> * CurlHandle::setOptionString(int $option, string $value): CurlHandle
> * etc... as needed, will this get weird when we get to Array since there IS
> a setOptArray? Maybe we just don't mirror that one, or we call it
> setOptionMany(). Yeah, I like Many for the multiple option set, and Array for
> the single option of array type.
> Internally, the setopt handler will be split by type so that each typed
> setting can call explicitly, and the untyped one can call all.
What about making the CURL options an enumeration? It would allow us
to typehint the setOptions() method and we can also make it backwards
compatible with the existing global constants:
```php
public function setOption(CurlOption|int $option, mixed $value): static
{
if (is_int($option)) {
$option = CurlOption::createFromConstant($option);
}
// ...
}
```
The enumeration would then have a static method to transform the
global constant into a native type (which we can do internally).
Naming is obvious just TBD. The biggest potential issue I can see with
this approach is the many conditionally defined constants from older
CURL versions/feature flags from compile time.
>From the many type variants of setOptions(), I am uncertain about
that, because with an enumeration, we would still need to have some
sort of whitelisting of what options can be passed into the method.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
Re: [PHP-DEV] Request karma privileges to vote on PHP RFCs
Hi Nuno Den tirs. 4. jul. 2023 kl. 22.30 skrev Nuno Maduro : > > Hi Internals, > > I am writing to request karma privileges to vote on PHP RFCs. > > For those who don't know me, my name is Nuno Maduro > <https://twitter.com/enunomaduro>, and I am a member of the Laravel > <https://github.com/nunomaduro/> core team. I have been involved in > developing and maintaining various Laravel tools and framework features > that are widely used by companies worldwide. > > I'm also the creator and maintainer <https://github.com/nunomaduro> of > several popular open source projects like PEST <https://pestphp.com/>, PHP > Insights, Laravel Zero, Collision, Larastan, Termwind, OpenAI for PHP, and > more. These projects have been downloaded millions of times and have made a > positive impact on the PHP ecosystem. > > As a speaker, I've had the opportunity to present at conferences in many > countries, including Laracons, PHP Italy, Forum PHP, PHP Serbia, PHP UK > Conference, PHPTek, and more. My talks usually revolve around the > open-source tools I've built, PHP, Laravel, and include live code > demonstrations. > > I believe having a Laravel core team member on the list of members with > voting rights would be incredibly valuable to the internals team. I have a > strong connection with the Laravel community, and I believe it's essential > to have their representation in the decision-making process. I too believe that it is important to have people involved in the decision making process, however if you are not an active participant of the internals community, then I cannot see how having voting rights will change anything. Searching the old archives I found 4 mails from 2021 (the first prior to this) in regards to an RFC of yours, 1 for a comment regarding a change suggestion and 3 from a first version of your RFC. Neither do I see any engagement or similar on our Github, Bug tracker (1 cosmetic change to the test runner) or similar projects within the PHP.net project umbrella. If you are only involved with the voting part but not the technical part, then I have a hard time seeing this being anything other than some badge of honor, sorry. While your resume is very impressive for sure, it does not tell me that you are involved with the internals eco system and take part of it, to me it looks like you just want to vote without investing more time in the internals community. I believe any reasonable person would have taken part of existing discussions and contributions within the PHP.net project. I would suggest to read Dan's reply and collect feedback if you feel that you are a representing the Laravel community and start there. We often hear feedback from other projects, but I cannot remember a recent time where Laravel representative gave feedback to a discussion or contributed (arguably my memory like most others is not the best). I cannot see how this should be granted at the current state -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ericmann
Den ons. 3. maj 2023 kl. 04.43 skrev PHP Group : > VCS Account Approved: ericmann approved by kalle \o/ Welcome aboard Eric! -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Removing OS2 specific code
Hi Den tir. 15. nov. 2022 kl. 10.08 skrev G. P. B. : > > Hello internal, > > While working on a bug, I've encountered some compatibility code for OS2, > which I've planned to remove, as the last release of OS2 was in December > 2001. > > This is to ask if anyone has any objections to removing compatibility for > OS2. Makes sense to go ahead, I removed NetWare and BeOS2000 support years ago that died around the same time as that. Likely we aren't fully compatible elsewhere anyway -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den fre. 4. mar. 2022 kl. 01.38 skrev Eugene Sidelnyk : > > You can't just go the usual way like nothing happens. This is the same as if > you know someone dying and say: well, I can't help with anything, so I will > do nothing against it. Inaction in such cases offends people. Banner is the > least possible, still useful way to help and people will know you are trying > to help whatever you think you can help. Trying to push on people's feelings is also offending, or rather trying to weaponize it as part of your personal agenda to get what you want. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den fre. 4. mar. 2022 kl. 01.18 skrev Lynn : > Not making a statement is also making a statement. I disagree, assuming a stance without understanding the context is insanity -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den tor. 3. mar. 2022 kl. 20.29 skrev Eugene Sidelnyk : > > BTW, regarding symfony and banner, it doesn't seem to have many (if any) > issues in github flooded. So what's the problem? The problem is making a political statement. This is not something the PHP project does; you may think that it means the PHP project doesn't care and that is in your right to do so. However it is not the place for PHP to make a statement on this matter, nor is it on other matters. You are welcome to promote this on your own social media platforms and websites. The general statements made here by you tonight is more alike to being kafkatraps based on the phrasing, which I would refrain from (regardless of the topic being discussed). -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den tor. 3. mar. 2022 kl. 11.54 skrev Christian Schneider : > Even if a project stays neutral on most topics does not mean there is not a > threshold where joining a wide-spread appeal or sign of solidarity is the > right thing to do. Yeah and that same argument can be applied to both the examples I just mentioned above. How many projects joined the BLM movement too by making statements? And when will that be used as an argument to push the PHP project to make statements on every world event? > The question where you set that threshold is a different question. > Personally I'd support a banner on the website but won't hold it against > people who think otherwise. To me the question is rather binary, because like stated above, it can be used as an argument to force a reason for why something should be done. I understand the sentiment in the message trying to be conveyed, but I don't agree with turning the project into such a forum. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den tor. 3. mar. 2022 kl. 10.48 skrev Sergey Panteleev : > > I'd suggest making a PR with the News (press release) in web-php > and maybe discussing it already on GitHub, > since it would get more coverage and we can hear more opinions. The moment you do that, you put the PHP project into making a stance on every politics and world events, like BLM, are we also now gonna have an LGBT banner too? No, the PHP project is not a place for such. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den ons. 2. mar. 2022 kl. 18.33 skrev Victor Bolshov : > This is going to cause debate, I was sure about it. And if the community > agrees at least to state "NO WAR", that is already something. PHP is not a media, it is an open source project. While our individual contributors can choose to support a world event or condemn it, is fully up to them. Some projects that was linked in this thread, like Symfony who took a stance on the matter and it is in their right to do and help with the resources they choose to do, but I don't think that is a valid argument to force taking a stance here and change the politics of the PHP project. To reiterate, I understand where you are coming from but I don't agree with forcing a political stance for the PHP project. So my stance will not change on the matter, and I believe in neutrality from politics. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Den ons. 2. mar. 2022 kl. 14.51 skrev Marco Pivetta : > Please GTFO: we don't need more of Putin's propaganda over here, as they're > busy enough with butchering civilians over there. I heavily agree with this matter, the PHP project should remain neutral. Seeing this thread already makes me dread the idea of even considering such, even if it is done with the purest of intentions. Big -1 from me (and to all future proposals of similar political matter) -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Surveying interest regarding CMake
Hi Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. : > Yes, gradually phasing the current build system out is the most > pragmatic choice, although it will incur some extra maintenance cost for > the time it's still in use, but it's better to do something sooner than > later. This will also allow php-src to drop the Windows SDK altogether > that was recently moved to the GH org, because Microsoft stopped > maintenance. I feel it is important to clarify something here. The Windows SDK is still supported by Microsoft. The Binary SDK for PHP by Microsoft which is the SDK that manages dependencies and provides cross MSVC environment build scripts is no longer supported. You can still build PHP on Windows without the Binary SDK but you will have to manage the build depedencies in all their flavors manually without this Binary SDK for PHP. Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen
Den man. 13. dec. 2021 kl. 12.53 skrev Oliver Nybroe : > What do people think about this? Would love to clarify if needed. > > Best regards > Oliver Nybroe (he/him) I find this to be more a problem to be solved by individual coding standards and cs tools. The !instanceof syntax is awkward at best, at least I find it to be so because it is mixing a symbol with a word to form an operator. The documentation already states the following[1]: > Use of parentheses, even when not strictly necessary, can often increase > readability of the code by making grouping explicit rather than relying on > the implicit operator precedence and associativity. [1] https://www.php.net/manual/en/language.operators.precedence.php -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] timelib performance fix
Den tir. 31. aug. 2021 kl. 09.10 skrev Pierre Joye : > It is late in the run to include it, but if RMs are OK, I would be all > for applying it. The lib is bundled and whether the external > repository applies it should not be relevant at this point (also no > activity in 2 years there), or? The external library is important because you can update the pecl release of that in the middle of a PHP release if an update comes out, which is good if you are locked to a specific version of PHP. Loading in the pecl/timelib extension will override the internal version, however if this fix is only applied to the bundled library, but not synced upstream, then it breaks this philosophy. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Nullable intersection types
> Hey Patrick. > > This has been discussed already. See https://externals.io/message/115554 > <https://externals.io/message/115554> Only Joe replied in there, implying an OK, however Patrick is also an RM and if he raises a concern, then that is good grounds for concern as exceptions to the feature freeze has to be approved by the RM for that branch -- exaclty what Patrick is. > > TLDR; This is not a feature. It is to correct a mistake which is exactly what > the stabilisation phase is for. > Some people still think this should be for 8.2. > The discussion started 4(!) months before the release of 8.1. It is now more > than 3(!) months before release of 8.1. The same argument could also have been made that there was 4 months of discussions without this being put forward, but let's not go down that path, the decision to halt this vote (if desired), is with the RMs, not the internal contributors. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add PDO function: mysqlGetWarningCount
Den man. 26. jul. 2021 kl. 15.49 skrev Peter Cowburn : > This date has passed, yet the vote is still ongoing. > Daniel, could you please close the vote and do the usual follow up tasks? > If Daniel is unavailable, what is the process for *someone else* doing > those things? I took the liberty to close the vote and moved the RFC to the Withdrawn section given its supposedly abandoned status -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Request for karma to vote on RFCs
Den man. 19. jul. 2021 kl. 13.14 skrev Lynn : > Currently there are people with voting permissions that do vote, yet do not > interact with RFCs or the mailing list. Regardless of the reasons one may > have for wanting to vote, the requirements given should be applied equally if > this is the argument. If this is a problem, then why has the voting RFC not been amended to require such commentary? That seems like a productive first step in solving the issue instead of complaining about it not happening automatically > Yes, and I love it when I see new users interact with the mailing list, even > when in the end the questions or arguments changed nothing to the RFC. It > shows that people are probably invested. How do you measure investment behind > the scenes though? How often has someone decided to not post anything on the > mailing list because after testing a bunch of changes proposed, it worked and > required no comment? How can I take that into consideration if no one lets me know about that? This argument sounds more to me like an illusion, I cannot read minds nor am I into experimentation on the matter, I cannot consider what I do not know (similarly to the problem you pointed out above). > Would every user that one day would want to have voting rights post a "yes I > agree" message in every thread in order to show they contribute in > discussions? That is not what I was implying and I am certain you know that. I specifically mean the discussions, not the voting itself. Taking Tobias here as an example, why is there no feedback from him on the RFCs like[1][2][3] (which was recent as in 8.1, this is just a list from a quick glance which may or not be accurate), they seem to me like an good way he could have given feedback based on the work he put forward that he had been involved with. Why is it that political power should just be given without actually taking part of the project and problems here at the PHP project? To me that comes off as laziness. "I just want to vote, but take no responsibility of maintaining the PHP project" [1] https://wiki.php.net/rfc/curl_user_agent [2] https://wiki.php.net/rfc/fsync_function [3] https://wiki.php.net/rfc/fibers -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Request for karma to vote on RFCs
Den man. 19. jul. 2021 kl. 12.11 skrev Lynn : > I fully agree with this, as a developer I do not want to worry about low > level php changes that do not directly impact me. Therefore I think that > people who do get impacted by this (for example open-source package > managers), at least get a vote in these changes. It's unfair to put the > burden of writing abstractions on someone and then tell them they don't get a > say in making their lives easier or more difficult. Why is it then fair to give them voting rights if they only contribute their vote but not words before hand? Why is it only possible to give feedback in terms of a +1 or -1 and not feedback in text form? Because if its only possible in that way, it makes me think that it is purely a PR thing which makes me worry that the power vested into the voter may not be just. Why is there no dialogs from their side on internals with problems they may have with directions? So far I do see a few faces from the community like representives static analyzers, Nicolas Grekas and Marco Pivetta to name some who actively takes part of the challenges at hand and even actively runs RFCs on their own with implementation patches, which is fantastic and well deserved in my opinion. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Request for karma to vote on RFCs
Hi Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm : > > 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. I'm not comfortable with this if this is indeed your first person to internals. There was a similar concern with the maintainer of PHPStan a while ago, who while also have a large set of downloaded packages, did not participate in the internals community by actively taking part of the conversation at the time at least and the request turned out to be declined. -1 from me to prevent discrimination and keep it consistent. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Refactor
Den tir. 8. jun. 2021 kl. 17.02 skrev Kalle Sommer Nielsen : > In layman terms > that means that Zend has more decision making power over any > individual contributor. Seems like I did a freudian slip, the above should read as following; "In layman terms that means Zend has *no* more decision making power of any individual contributor" -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Refactor
Den man. 7. jun. 2021 kl. 13.52 skrev Mail : > > Oh yes; it is; > > Mathew from Laminas has also held managerial position in Zend. > Thats the one who banned me ( on Laminas forum ) when I asked about the > comments section refering to Zend in every file. > > If you want to cut ties with Zend alltogether,first thing to do is to remove > every person that have been involved with Zend. Once done, start afresh. > > Pozdrawiam, > Wojciech Lisik Well since you kind of figured out the response was not serious, then I am certain that if you look closer at the code you will find that we naturally are not using Zend Framework as it is a piece of software written in PHP but Zend Engine is written in C. One being a framework for writing websites, the other one being a highly advanced scripting engine. I will save you the need to Google what the differences is here by supplying you with some relevant links: https://en.wikipedia.org/wiki/Laminas https://en.wikipedia.org/wiki/Zend_Engine https://www.zend.com/about So to iterate and reply to your email in a serious manner; No, we have no intention to refactor out the Zend Engine. It has been maintained by The PHP Project for two decades and while it was originally developed by Zend, it was graciously donated to The PHP Project and The PHP Project decides the future development of it. In layman terms that means that Zend has more decision making power over any individual contributor. It is however true that some companies, like Zend, does sponsor developers to work part time at The PHP Project but that does not grant them any special decision making rights -- those are still subject to the democracy and guidelines as defined by The PHP Project. At the same time I would like to point you to the list of mailing list rules: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md Especially the part about respective behavior and not making a fool of yourself in public; none of your initial mail was informative nor respectful to anyone maintaining PHP, which seems to be based on a wrong understanding to begin with (which is only natural, we are only humans after all), but do think an extra time before you post a rant like that in the future, it does not belong on internals. Twitter is a much better medium for such. I'm certain that exhitibing the same behavior as defined in our mailing lists rules, will also get you a long way on other platforms, like the Laminas forum which you mentioned. ps, I have CC'd internals, so this reply may serve as a future reference; should this ever be the case again. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Refactor
Hi Den søn. 6. jun. 2021 kl. 18.39 skrev Mail : > > As I was browsing through php source Ive noticed EVERY file has comments > related to this shitty zend framework. > > Make php pure pleasure. Currently its fucking PAIN. Thank you very much for your interest in PHP, it's always great to hear from our many great developers! To answer your question; I too have been feeling the same regarding our backend. I had a discussion with some our other Core Developers and we have decided that coming PHP 8.1.0, we will be switching to using Laminas. I hope this will be to your satisfactory! Thanks again for the feedback and for helping us make PHP even greater. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd
Den søn. 6. jun. 2021 kl. 00.09 skrev Ayesh Karunaratne : > > Hi Ben, > Thank you for opening this PR and the discussion. With the wide > availability of AVIF/AV1 support in browsers, I think this will fit > nicely. > > We have the Namespaces in Bundled Extensions RFC > (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so > perhaps, the new functions are probably better in the `Gd` namespace? > This would mean the new functions would be `\Gd\imagecreatefromavif` > and `\Gd\imageavif`. They are inconsistent with the existing functions > of course, but I thought to mention it because it's a recent proposal > and I don't think we added new functions after that RFC. Some examples > are recently renamed PHP classes in IMAP, Pgsql, LDAP, and FTP > extensions to follow this new proposal. I don't think it makes much sense to do that for a single function, because it makes the API cluttered, as why would I call `\Gd\imagecreatefromavif` when everything else is in the global namespace? That is a poor design, while I understand the intentions behind it is good. I think this needs to be well thoughtout in a topic on its own rather than off topicing it here, so I will leave it at that. Overall, +1 for adding this -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Could we drop the bottom-posting rule?
Den tir. 11. maj 2021 kl. 00.52 skrev Kamil Tekiela : > Could we please change this rule or at least stop enforcing it? > Do people actually have mail clients that don't automatically hide the > previous conversation? If not, then I think we can let people top-post. -1. I feel the same as Stas does here. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Bugsnet
Den søn. 9. maj 2021 kl. 09.49 skrev Joe Watkins : > > Morning internals, > > We have a spam problem on bugsnet, it's not a new problem. Nikita had to > waste time deleting 20 odd messages from bugsnet yesterday and this is a > common, daily occurrence. We clearly don't have time for this. Big +1 from my side. Much like Joe, I have tried a couple of times over the years to keep the old bugsnet up to date, but it is simply not possible to do in its current state -- for example, there is still open feature requests from 2001 there. One can also open that it can keep other spammers and abusers away from the platform such as the ever so recurring abuse of Reindl Harald. I only think the transition period will be difficult, but it should iron itself out after a year or so (hopefully) and I assume that by then, we could perhaps have a better medium or idea of how to deal with security bugs based on the tools available to us after some time of using Github on a project of the scale of PHP. I also fully agree that it is not something we should vote on, it is one of those things that those who actively work on PHP should decide (to semi quote Rasmus) -- Let's make it happen. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Why am I unable to use 'readline_on_new_line()' on my windows machine?
Den tor. 29. apr. 2021 kl. 18.50 skrev Hamza Ahmad : > > Hello Internals, > I am unable to call readline_on_new_line() function. > I am posting this to internals to confirm whether it is a bug or an issue > with docs. Please report such things on the bug tracker first always, so it can be checked there -- that part of why we have a bug tracker, to confirm such things or not. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Changes to Git commit workflow
Hi Bishop Den tor. 1. apr. 2021 kl. 07.55 skrev Bishop Bettini : > I've documented why we need signing, and how to set it up: > > https://wiki.php.net/vcs/commit-signing > > Feedback welcomed! Great guide, any chance to add some Windows information here? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Changes to Git commit workflow
Den man. 29. mar. 2021 kl. 01.52 skrev Nikita Popov : > While previously write access to repositories was handled through our > home-grown karma system, you will now need to be part of the php organization > on GitHub. If you are not part of the organization yet, or don't have access > to a repository you should have access to, contact me at ni...@php.net with > your php.net and GitHub account names, as well as the permissions you're > currently missing. Membership in the organization requires 2FA to be enabled. How will this work for SVNROOT karma holders to grant karma to others going forward? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
Den søn. 28. mar. 2021 kl. 14.30 skrev Deleu :
>
> The fact that short closure is inconsistent with the rest of PHP is a done
> deal since the voting passed prior to 7.4 release. Unless there's a follow-up
> to deprecate the 7.4 short closure auto capture without `auto` keyword and
> make it look like PHP can't make up it's mind, I feel that your perspective
> doesn't match the proposed RFC. The RFC is extending short closure to support
> multiple statements and defining good semantics on how developers will
> interpret fn, => and {} throughout the language.
I think we have some sort of conundrum. I am not saying auto capture
is not good semantics if that is what you are implying, I more than
anyone would like consistency in the language but it is not a good
language design to have two very similar features separated by a
shorter keyword which implies totally different semantics. I don't
find this a very intuitive way nor a good developer experience. I can
understand that the connection of the `fn` keyword already having the
meaning it has, but then we can bring up the side running RFC from
Larry which proposes to make the same short syntax available for other
function declarations, how would this work then with this mindset of
`fn` meaning auto capture? Does that mean a procedural function
declared with `fn` will now inherit the scope from which it was
declared (usually the global scope)? What about methods declarations,
do they import properties into the local scope? How does traits
interact here, same as methods?
This is why I think having the `fn` being an alias of `function`
neutralizes the argument of what happens for exactly those reasonings
above, this allows arrow functions to continue being auto capture
without any keyword. And again; adding an `auto` keyword is also not
an alien thing to Closures because we already have the `static`
keyword which acts as a feature flag, something which arrow functions
already support which also is a case that can easily mess up the order
of which objects are destructed in if you make a Closure that does not
interact with `$this` from an object context without declaring it as
`static`.
While I did not agree with this in the initial RFC that implemented
arrow functions, I do see its value and agree with it due to the
narrow scope of which arrow functions have, and therefore I think it
is fine to have the exception of making arrow functions behave this
way and would have voted as such had it come to my desk today.
And again, kindly stop top posting.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
Den søn. 28. mar. 2021 kl. 13.02 skrev Deleu : > > This would lead to inconsistent behavior in the language when short closures > auto capture without the auto keyword while multi statements closure doesn't. > One of the best features of these RFC are their cognitive definition that is > clear, concise, consistent and simple. (First off, please read our mailing lists rules[1] and do not top post) If we go by the inconsistent behavior then by that definition short arrow functions are inconsistent with the rest of PHP as there is no auto capture elsewhere. This is not short arrow functions being expanded to support multi lines, but rather the other way around, with multi line closures being able to support auto capture which is identified by the `fn` keyword and because of that, I would much rather have a `fn` be an alias of `function` and then having the ability to put a keyword to declare that you wish to use auto capture (which is consistent with the exisiting design of PHP where you have to declare globals with the `global` keyword or explicit imports to closures with the `use` statement (which used to be done by the `lexical` keyword similarily to the `global` keyword in early PHP 5.3.0 development) -- if you are interested in this philosophy you can try lookup videos from some of Rasmus' presentations where he explains his dislike with globals coming from C). To back this up further, we also have the `static` keyword which acts as a feature flag so it is not unnatural, the naming of the keyword `auto` sure, but that is another discussion. [1] https://git.php.net/?p=php-src.git;a=blob_plain;f=docs/mailinglist-rules.md;hb=HEAD regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
Hi Rowan
Den lør. 27. mar. 2021 kl. 18.05 skrev Rowan Tommins :
> Based on those, there seems to be no way to prevent a variable being
> captured, even if its value is immediately discarded each time the
> closure runs. This may be less than ideal:
>
> $results = getLargeReportFromDatabase();
> // ...
> $fn = fn() {
> $results = []; // coincidentally the same name, immediately
> assigned its own value
> // ...
> }
> unset($results); // does not free the array, because $fn has captured
> the value
I too am very concerned about this exact senario because it very
easily overlooked. While I understand the appeal of having very short
closures, I do think that such behavior needs to be explicit and would
much rather prefer something like this:
- Make the `fn` keyword an alias of the `function` keyword
- Add a new `auto` (or similar) keyword for explicit auto capture
Something like this:
```php
return function () use ($v1, $v2, $v3, $v4) {
/* ... */
};
```
Would then be abled to be turned into:
```php
return auto fn () {
/* ... */
};
```
That way it is very clear that the closure is intending on auto
capturing at this point, at the same time it also allows people like
me who prefers the `function` keyword to write.
I personally don't think adding those 5 extra characters here for
explicitity is bad, I would like explicitly over implicitit, I can see
how many would simply just write `fn` without knowing there is a very
vitual difference (similar to `static` closures is rare if you don't
intend on binding `$this`).
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi Den man. 22. mar. 2021 kl. 11.25 skrev Nikita Popov : > > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 I'd like to suggest adding `nl_langinfo()` to the list of deprecations, it is a non-cross platform oddity that make less sense with the current deprecations of functions like `strptime()` (also non-cross platform) and `strftime()`. Personally I have seen more code in the wild use array derefencing on `localeconv()` (which is cross platform) over using `nl_langinfo()` for a single category. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fibers
Den ons. 10. mar. 2021 kl. 20.22 skrev Dan Ackroyd : > > Hi internals, > > Well, technically this is addressed more to people who read internals. > > Please don't contact people off list putting pressure on them to vote > in a particular way. > > It _really_ is not appreciated, no matter how well intentioned the > sender thinks it is. For the sake of integrity, I believe the vote should be halted and restarted at a later date to prevent the influence of referenced email from having a favored vote. This has no relation to my personal vote on the matter of the RFC however. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] PHP\iterable\any() and all() on iterables
Den man. 8. feb. 2021 kl. 17.08 skrev Levi Morrison via internals : > - I do not like the chosen namespace. This is not as important as the > previous point, but still factored into my decision as we are still > very early in choosing namespaces for internals. I don't want to vote > for something I think is a bad direction when we're this early on. I'm in a similar boat as Levi, I like the functionality but the choosen namespace is what caused my no vote. We had 2 RFCs last year talking about the namespace question and it is yet to be answered -- I don't think this RFC or any other should go into the core as it could force the answer to the namespace question. Having them in \ would be a +1 from me tho. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?
Den fre. 15. jan. 2021 kl. 00.30 skrev Reindl Harald (privat) : > to make it easier for you: AUSTRIA not germany - similar laws but wrong > country, you waste time to sue me in germany I don't really care where it is, matter of the fact is that you are incapable of acting like a reasonable human being. Whether or not you are aware of it or totally oblivious to it baffles me. Your contious efforts to try and harass members of our community is a stain on the open source community as a whole and not something we as the PHP project wish to help you fascilitate. > what a fuss because calling someone who pretends "don't run your own > server, nobody does for 10 years now, the cloud is your way" what he > deserves > > if i would asked you little fuckers for your optionoin i would have sent > it to the list, other than most of you i am capable to operate a mail client > > come on - sue me - and until then kiss me wehre no sun ever shines - > hopefully) I don't think anyone is interested in sueing you, quite the contrary, what we wish is for you to stop messaging people via the PHP project's infrastructure. If you wish to continue this act of yours, then please take it elsewhere (while I personally hope you will instead seek help or similar to deal with the issues or what not that may be behind this). However if there is no way for you to change your mind and let the PHP project be outside your abusive ring, then we as a project has to find out what our legal option is to make sure that you cannot continue to abuse our maintainers, contributors, users, among others. I hope you will rethink your stance and give up this crusade of yours, Thank you -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?
Hi > Hi, > > On the 7th Apr 2012 Reindl Harald was blocked from php internals: > https://news-web.php.net/php.internals/59421 > > It appears he is working around this block by using an alternative > name for the same domain: > https://news-web.php.net/php.internals/112344 (Although the email > sender doesn't display correctly in that link, in my email it is > displayed as "Reindl Harald (privat) harry at rhsoft.net") or an > alternative domain: https://news-web.php.net/php.internals/109274 > > Please can someone remind me what the procedure is to block email > addresses from the internals list? > > He's also apparently has been emailing people individually off-list > according to: https://news-web.php.net/php.internals/112833 > > 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. > > Obviously the emails being not sent through the list, makes it > difficult to do something, but it's worth trying. > > He's also been repeatedly abusive to people on bugs.php.net, which > probably needs to be addressed at some point. > > The email addresses I believe are associated with him are: > > 'spam2 rhsoft net', > 'phpbugreports gmail com', > 'bugreports2 gmail com', > 'bugreports gmail com', > 'phpbugreports gmail com', > 'bugreports2 gmail com', > 'bugreports3 gmail com', > 'bugreportuser+php bugs gmail com', > 'bugreport example com', > 'bugreports1 gmail com', > 'bugreport2 gmail com', > 'bugreports gmaill com', > 'rtrtrtrtrt dfdfdfdf dfd', > 'h.reindl thelounge net', > 'lists rhsoft net', > > So if anyone's received abusive content from any of those, please > either forward to the list, or to dan...@php.net This has been an ongoing issue for him for as long as I can remember being part of the PHP project which is well over a decade. PHP is not the only project where he has been abusive to: https://pagure.io/CoC/issue/6 Since this is an endless battle, I do not see any other option than taking the battle to legal authorities in Germany (assuming that is where he is located based on name/email locale), not sure if the NetzDG or STGB 185 applies here, but it is worth finding out as this abuse has gone on for far too long now and it is time to make it end. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array unpacking with string keys
Den tor. 7. jan. 2021 kl. 21.19 skrev Larry Garfield : > Hard yes. I ran into a case just yesterday (while doing some sample code for > immutability) when I wanted to merge associative arrays this way and the > alternate was much yuckier. Seconded, I ran into a similar thing yesterday and it took me a bit to figure out what was going on. This RFC would fix that behavior so big +1 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8 release announcement page on php.net
Hi Den man. 12. okt. 2020 kl. 10.57 skrev Roman Pronskiy : > https://i.imgur.com/6fKmTyM.jpg The concept looks great, however in the current state, it cannot go in like that which mainly comes down to neutrality. - This means we cannot display projects such as Symfony, Laravel and WordPress at the top.Sure they are popular, but we cannot promote them. - At the same time we cannot have the community leaders section and potentially not the one beneath that, again this comes down to neutrality and not to show any sort of favoritism. Note we do not link to Core Developer blogs or anything like that, the closet you would get to that is people.php.net, and even that is limited. This basically means that at best, this page can be a glorified migration page with code examples and new features presented in a long page style layout (unlike the sectioned multi page style that the manual traditionally has), which I would be perfectly fine with and accept if posted as a PR for php-web on Github. Personal side note here: I would prefer to keep the written language similar to existing style on PHP.net for consistency, the "overselling" part is personally a bit too much for me, and more something I would expect to read on pages like Zend.com that has a business gain for getting users on PHP8 or whatnot, however not a deal-breaker for me. However the most important thing I see here is to actually begin documenting these features, as linking to their RFCs, is not the way we should document features. I'm currently not aware of what the status is on that, but given the last few versions of PHP, we are probably far from a state where PHP8 is broadly available in the manual. This naturally is not a blocker for this project, but a consideration. Also note that anything related to the websites belong to the php-webmaster@ mailing list, *not* internals and I would highly recommend moving the thread there. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables
Den tor. 3. sep. 2020 kl. 15.18 skrev Nikita Popov : > The main thing I'm concerned about is that once we start extending this > area (I assume that any & all are not going to be the last additions in > this space) we will quickly run into function names that are either too > generic or outright collide. For example, what if we want to add an > iterator-based version of range()? Do we *really* want to be forced to pull > a Python and call it xrange()? That's about as good as real_range()... I agree with this point, and we already have some `iterator_*` functions in ext/spl. Such as `iterator_to_array()`, `iterator_count()` and `iterator_apply()`, so that prefix is somewhat available to use for consistency. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Community vote on RFCs
Den fre. 21. aug. 2020 kl. 09.03 skrev Brent Roose : > What about people who occasionaly contribute to docs? Are they more eligable > to vote than someone like Nicalos Grekas? It's a good thing he got voting > rights, but in my mind that should have been a no-brainer. I realise some > people might get upset with this point of view, but I don't think that > occasionaly contributing to PHP docs makes you a better representative than > having actively shaped the PHP landscape over the past decade. Difference is that people who "occasionally" contribute to docs are involved with the PHP project, they are contributors, not users. So yes they are more eligible to vote because that is the privilege that they earn by being contributors, not users. Sure we have a high barrier of entry, but if we let the floodgates open for any abled soul to begin voting and judging then we would never get anything productive done. The RFC experiment on Github was a mess, sure there was some valuable feedback there but there was a multitude of equal feedback that was useless because it was so open. > How many people have voting rights? Over 200 if I'm not mistaken? How many of > those have been activly contributing to PHP for over the past year? I think > that's a better question to answer. If half of those people's voting rights > get revoked then maybe there's room to allow a few more key community figures > to participate? There are 1876 VCS accounts and then we have a number of wiki only users who can vote. We have no metrics that can measure such, because a lot of things happen behind the scenes that you see. The discussion that I referenced in my earlier reply that took place last year tried to revoke existing contributors from their right to vote that they have earned by using the amount of commits or something in that direction as a metric to tell if a contributor was "active". Neither do we have a process to clean this, and for most project members that seems fine so it has not changed. What baffles me is that non project contributors really seem interested in taking a stab at this without really being involved in the project in any way. If you want to have the right to vote, then please earn it by being a part of the project. If I want the right to vote on features in userland projects, then I would also earn it like a regular contributor if I wanted it so dearly. It really does not take much effort. There is nothing that stops an RFC author from surveying userland various communities before they seek to have it accepted into PHP proper. Twitter is a decent place to do so. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Community vote on RFCs
Den tor. 20. aug. 2020 kl. 01.07 skrev Stanislav Malyshev : > Please feel welcome to. However, I don't think this should have any > official role in any PHP governance process, any more than any other > poll on the internet might. That said, my opinion is hearing other > opinions is rarely harmful and frequently useful, so why not. I very much agree with Stas here. I think it should be up to the individual RFC author to put out feelers for feedback from userland, because going to internals is the final judgement. Regarding the link to the thread in the initial email, while it is not impossible to get voting rights. There is a very high barrier of entry, if you are not involved with the PHP project, then being granted voting rights is absurd and can easily flood the usual Core Developer voting turnout, we had a similar debate about this in the spring of 2019 in regards to the PHP FIG which was heavily disputed. Anyone who is not actively involved with the PHP project, is not someone I can feel safe with granting the right to vote. Should I also gain the right at any PHP based project to vote on whatever democratic process they have because I am a maintainer of PHP? No I shouldn't. If I'm involved with a project in question, then that changes the perspective but it is still up to the project to decide on how to proceed here. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Voting access
Den søn. 16. aug. 2020 kl. 12.08 skrev Michael Voříšek - ČVUT FEL : > > Hello, > > based on https://wiki.php.net/rfc/voting voting access is offered to > people who: > > - contributed to PHP source - I have made several smaller contributions > to php-src incl. + some core xdebug optimization > > - lead developers of PHP based projects - I contributed to Symfony, Mink > and some data php frameworks, about 500 PRs to PHP based projects > totally in past year You missed parts of the text: ``` - People with php.net VCS accounts that have contributed code to PHP - Representatives from the PHP community, that will be chosen by those with php.net VCS accounts - Lead developers of PHP based projects (frameworks, cms, tools, etc.) - regular participant of internals discussions ``` You do not have a VCS account, so you do not qualify for the first part,, the second part is existing people with VCS accounts choose you which has not happened here (you requested yourself). Looking deeper at the second one, I do not see you mentioning you are a lead developer of either (the metric of your PRs is an irrelevant metric here according to the text), nor would I call you a regular internals participant (I found 6 posts total from you). > Is this reasonable enought ti gain the voitng access and who should I > contact? Based on the above, I do not see it being close to reasonable. If you wish to earn the privilege of voting, you should be more involved with the project as a whole. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
Den ons. 12. aug. 2020 kl. 18.29 skrev Paul M. Jones : > It's premature. If we can't follow our own rules, why even have them? Agreed -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Registration on wiki
tir. 28. jul. 2020 kl. 08.39 skrev [ ] : > When I try to register on https://wiki.php.net/?do=register , > <https://wiki.php.net/?do=register> > Such error is generated: "That wasn't the answer we were expecting". This means you failed the captcha on the registration form, please read the page in detail and it should be a walk in the park. -K > -- regards, Kalle Sommer Nielsen ka...@php.net
Re: [PHP-DEV] Changing default assertion mode to throw exceptions
Hi Den man. 13. jul. 2020 kl. 20.37 skrev Levi Morrison : > > Hello everyone, > > I'd like to change the default mode of assertion failures to throw. > The current default is to warn. In my opinion this is a bad strategy: > the engine asserted that something that is expected to be true is not, > so executing further is a bad idea. This leaves throwing or bailing > out. I think throwing an exception is better than bailing out, so > that's what I propose. +1 on this. I was recently surprised why this wasn't the default either -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: ondrejmirtes
Hi Den lør. 11. jul. 2020 kl. 08.55 skrev Ondřej Mirtes : > Oh, thank you. Should I fill out this form? https://wiki.php.net/?do=register Yes that is the one. Someone with wiki admin karma needs to grant you the right write permission once that is done. When you have registered, then send off an email similar to the VCS from this thread (state your wiki username and intentions) to the internals mailing list. > What email should I use for the "To which email address do you have to send > an email to now?" field? This should be the internals mailing list address. The information to fill out this spam challenge seems to have been lost sometime when we upgraded the wiki software but never fixed. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: ondrejmirtes
Hi Den lør. 11. jul. 2020 kl. 08.43 skrev Ondřej Mirtes : > > The main reason is to be able to vote on PHP RFCs. I\ve created > PHPStan, a popular open-source static analyser. > > This submission is endorsed by Gabriel Caruso, a current release manager of > PHP 8. You do not need a VCS account for that, but rather a Wiki account if that is your sole purpose (similar to fatpot from Symfony). -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Hello Internals The voting has closed with 44 for and 30 against. The RFC has not been accepted as it did not meet the 2/3 requirement to be approved, thank you to everyone for joining the discussions and turned out to vote. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Tiny tweak to mail list please
Hi Den tir. 16. jun. 2020 kl. 15.33 skrev Alain D D Williams : > > Below is the standard footer to all list emails. > > It refers to an address that starts http:// - please can this be changed to > https:// - which is what you get redirected to. Send an email to syst...@php.net, they should be able to handle something like this. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList
Hi Den tir. 16. jun. 2020 kl. 15.15 skrev Michał Brzuchalski : > > Hi Internals, > > 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. I disagree with this statement, and I do not believe that just because you think it is a better terminology, it should be justifying the BC break that comes with this change. Like I expressed in the PR when it was originally posted and the other topic currently active on internals that it seems much like a change for the sake of change. This is clearly a political change and something we as a project should refrain from doing. If this RFC comes to pass, are we going to change the PHP.net logo to declare our political allegiance to the cause in America? Attempting to change something which has no correlation to racial remarks but using it as an argument that it can be is an absurd argument to me. > The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist The pull request in the linked RFC does not seem to reflect all the details of this RFC, the PR also changes the whitelist to allowlist, something that is not noted in the RFC itself among other things, or did I miss something? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Den tir. 16. jun. 2020 kl. 03.30 skrev Daniel Rodrigues Lima : > > How is it in the process of creating an RFC... > > "1. Email internals@lists.php.net to measure reaction to your intended > proposal. " That is the thing, do you intend to provide no upgrade path for your proposal? You don't mention what version of PHP you are even targeting, or am I to understand that your proposal has none? Does it mean that these changes goes into the next releases of 7.3.x, 7.4.x and 8.0.0? Is it only 8.0.0? etc. these are all basic questions that any other RFC proposal answers when it is brought to the mailing list. You can search the mail archives to get some examples of how it usually is laid out. To clarify, you sent a discussion topic. There is nothing about any RFC intention in your first post (or subject line that most others do). Before a proposal can begin to be understood it has to be fleshed out, you need to have a solid argument for, upgrade paths, solutions to potential problems, open quests (you got a fair few from this thread alone) and so on, there is plenty of RFCs on the wiki you can use as a base example for yours. I think the confusion here is the misunderstanding of what the term "proposal" mean in the copied list point you sent me above. A proposal means the actual first version of the RFC, a soft version if you will. The complete list point is: Email internals@lists.php.net to measure reaction to your intended proposal. State who would implement the feature, or whether the proposal is only a “concept”. Proceed with an RFC if feedback is not negative or if a detailed RFC will clarify the proposal. Mail list subscription is at http://php.net/mailing-lists.php. (Reminder: always "bottom post" your replies. Never “top post”.) Your initial post does not state who should implement this feature either, or if this is only a concept. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Den tir. 16. jun. 2020 kl. 03.09 skrev Daniel Rodrigues Lima : > > I fully understand the consequences of the discussion we are having here. > Sorry, but it is not nice to assume things about any PHP member. I didn't > "throw a ball in the air at random", and I'm not scared by the negative > responses themselves, I'm just surprised in a negative way. If you fully understand the consequences of this conversation, then why was none of these potentially negatives laid out in the first post for topics of problems to be resolved? The analogy of "Throw the ball in the air randomly" was meant to show no research besides a few links was posted, there was no concrete plan that lists potential issues you would need to overcome to accomplish this in the first place, similar to what Nikita pointed out, there was no research done on this in the first place either. Which is why I doubt (assume) that you did not fully understand the consequences of the conversation, it did not leave me with the impression in any way that you did, if you say you do that now then okay I believe you. I am in no way implying you should be scared by the responses. But you still have not provided any potential direction you wish to take other than "What do you think about changing X symbol name to Y symbol name?" (if you boil the question down). You listed the only pro as using naming that does not cause negative feelings for black people specifically in your first post. There have been no cons listed either, you have heard some from some of the actual language maintainers and some for the community. You did not mention how you plan to tackle upgrade paths, targeted versions or anything. If you just throw the question out there without a concrete plan to begin with, you are not gonna get far. If you however take an active lead and steer the direction of your plan, then the conversation would potentially look different because then you could begin to flesh out the problems at hand and come with a unified solution that could perhaps satisfy the audience that you need for this change to pass. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Den tir. 16. jun. 2020 kl. 02.39 skrev Daniel Rodrigues Lima : > > The simple fact that we don't know how to deal with this type of discussion > can say a lot about of our community. > Anyway when I started this discussion I didn't imagine that I would receive > so many negative feedbacks. I am sorry but I don't think you fully understand the implications it may have. I get it, there is no easy answer but while the change may be simple and elegant to rename a few places you may find problematic, you have to understand the consequence of the users it has and what statement it means the PHP project as a whole is sending. If we openly change these names without further, we also declare open season for changing anything anyone may find offensive in whatever way that may be in the language. It sends a strong signal to our users that reliable backwards compatibility policies we have inplace, which our users enjoy, may no longer be as reliable. This puts a greater burden on upgrading from one PHP version to another, if your time is just spent on search, replace and test for things like these. I mean personally I would much rather solve interesting problems and I do not find censoring words like blacklist into blocklist to be an interesting problem to solve, because I do not see it as a problem in the first place (either in my professional world, personally or as a PHP Core Developer). Right now you threw the ball in the air without looking and you seem amazed where it landed. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Den tir. 16. jun. 2020 kl. 02.12 skrev Deleu : > > > I am sorry but I do not think you understand the scale of which the > > PHP project is at. > > I'm sorry but you did not get my point. As mentioned above theres 170 places > mentioning the term blacklist. When I said "the argument of BC without > knowing the scope" I meant to express that perhaps 1, 10 or 100 of these > could be changed without any BC impact, meaning that perhaps they barely need > an RFC in the first place as it could potentially be just internal code. > Instead of being negative and dismissive of a chance at a diverse and > welcoming environment, let's see what we can easily do first and take the > first step towards making a statement in favor of a better community. So let me get this straight, you feel uneasy that internally in PHP there is something called blacklist, a variable or something that, and changing those are making a statement in favor of a better community. Well that is also a biased opinion, I am certain we can dispute what is better for the community for days without end. What purpose does it serve to change the internal variables from blacklist to blocklist when it still needs to interact with the term blacklist, why would we use two different terminologies for the same thing? I am being negative towards this change because like I have stated before that it is a change for the sake of change and I do not find the justifications presented here to be strong enough reason to break working code because you feel offended by some political propaganda that has made you believe that blacklist is a racial slur, or whatever it might be. Censoring industry terms that has correlation to racial remarks whatsoever sends a signal that "Hey the PHP project would rather allow breaking your code because it needs to be diverse", what happens when the next flavor of the month term comes that needs to be censored for whatever reason, should we then also break that? Because if that was the case we could do that nonstop. I still don't think it will make the community better by breaking already working code. To say that the current naming is not diverse and welcoming is almost disrespectful in itself. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Hi Den tir. 16. jun. 2020 kl. 00.41 skrev Deleu : > People arguing BC breaks without even knowing the scope of the change > clearly show biased. I am sorry but I do not think you understand the scale of which the PHP project is at. Any change we make to the language has consequences for hundreds of millions of websites running PHP, potentially millions of developers who work with PHP and so on. Therefore any change that breaks backwards compatibility in any way has to be justified. We have a rather strict BC policy, something that allowed you and millions of others to easily upgrade from PHP5 to PHP7 with next to no changes for the most part. Do I personally believe that a change of name for some directives, potentially more, are justified? No I do not. That is my personal bias here. Let's assume that 10% of the current user base of PHP upgrades to whatever version a change like this is implemented. The number of work hours spent on investigating, updating, testing and patching these BC breaks which are changes for the sake of change is a crazy amount of hours invested into it. Opcache is a very popular extension, changing an ini directive means change of build systems, you can certainly argue that these changes could potentially just be changed by a tool, but even doing so will have cost a substantial amount of hours to implement and test. It is easily in the thousands of hours, a normal work year for me is about 1900 hours in terms of hours for just one person. Demanding that our users should invest so many hours besides the usual amount for already upgrading to a PHP version is lunacy, especially if the change is to try censor something that has no correlation to any racial slurs. So to say that the arguments about BC breaks (which I believe I was the only one to post about in this thread) without knowing the scope of the change is void. Yes, any policy for backwards compatibility breaks can easily be classified as biased, because they are an opinion of the project as a whole, or rather, a policy. > As white men, we're being dismissive, insensitive and strongly suggesting > we don't want change. While people may not feel offended by any of these > terms being discussed, this thread alone already serves as reason for > people to feel like there's no room for diversity in the internal community > of php. The "we" in this is extremely biased, it attempts to force me to feel as an inferior human (to steal the term from Larry above), because I do not agree with your request for a change. The classification you just did there is something I personally would feel offended by, because you attempt to use my ethnicity as an argument for why I feel the way I feel. > I believe that if we cannot come together to take the small (potentially > insignificant) step towards making changes that signal a welcoming > environment, how are we going to actually take the big steps? We could start by taking steps that matters for once, censoring words that have no correlation to any racial issue because it might offend someone because it has the word black in it. What about whitespace? Am I a nothing, an empty space just because I am caucassian? There are other issues we should tackle to make PHP better, after all, we have a major version in the works, set to release later this year. Something (excuse my bias here) is way more important than trying to justify backwards compatibility breaks for no reason. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Den man. 15. jun. 2020 kl. 19.15 skrev Daniel Rodrigues Lima : > > Hi Kalle, > > I understand your position. > > But i believe that changing retrograde terminologies that refer to bad > feelings, > doesn't put us anywhere politically. It exactly puts us in a political area, because the moment we change these things we are effectively agreeing that this is a terminology (while unrelated to races) that should be censored. That is where the political stance begins. You are trying to censor something because you think it might be offensive to some, that is the first problem here. Any person raised with basic understanding of social etiquette and norms understand that these are not words that are offensive words, unlike so many other words. Claiming a word may be offensive to some without understanding the actual meaning of the word is poor judgement. > It's not about sides, it's about people, and our community is made up of > people. It puts us at different sides, because now you are playing on the feeling that it refers to bad feelings, and because it is a political agenda to censor, then it becomes about sides as there is never an agreement in a political spectrum. One thing your reply does not do either is to justify the BC break that any of these have on a grand scale. It might be fine to change your policy for your local medium sized open source project, but when you are dealing with something on the scale of PHP, you have to justify these changes and I still am not convinced that we should change these for the sake of changing. I get that the thread is to start a dialog, but I do not see any concrete plan here to justify these changes. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Hi Den man. 15. jun. 2020 kl. 18.43 skrev Daniel Rodrigues Lima : > > Hi internals, > > I think the time has come for the PHP internals to discuss the use of > master/slave and blacklist terminologies. > As everyone can see, we are going through times of change in the world, see > #blackLivesMatter for example. > Therefore, I propose that we discuss the non-use of terms master/slave, > because the use of this can allude to the slavery and negative feelings about > black people. We are an open source project and should be politically neutral, changing this not only causes a huge BC break, but puts us in a position where we are no longer politically neutral. You should be able to join and be a part of the PHP project without feeling obligated to follow certain global politics like trying to not use blacklist, master, slave or whatever flavour of the day word here that may be offensive to someone. The moment we change blacklist to blocklist, we are essentially agreeing to the fact that we should censor words because they contain a color in its name, something that is totally unrelated to any human race. Are we also gonna change the internal values of the Garbage Collector for PHP to not use different color markings or what about the IMG_BLACKMAN filter, are we gonna rename that even though it is named so after the Blackman-Turkey transformation? Of course we should not. We cannot go around and censor words that have no correlation to the current political events occurring world wide. This here is just an example of changing things for the sake of changing. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reserve keywords in PHP 8
Hi Den lør. 13. jun. 2020 kl. 22.10 skrev Ilija Tovilo : > > Hi internals > > I created a new RFC for reserving keywords we might need in PHP 8.x versions. > https://wiki.php.net/rfc/reserve_keywords_in_php_8 > > Let me know if there's something you'd like to work on that will > require a keyword and I will add it to the list. The keywords will > most likely be voted on separately. I do not see a point in soft reserving something we don't even know if it will make it into 8.x. I mean sure you might work on some of them, but they should be voted on a case by case basis. We did future reserve somethings in the past for PHP6, e.g. the "b" string prefix and the "(binary)" cast (for the then non unicode strings). See: https://3v4l.org/nFJHb We stopped trying to future proof code by soft reserving after PHP6 turned out to be nothing and most of the features were ported to PHP5.3. I don't think we should go down that path again of soft reserving something before we can guarantee it will be implemented, something we cannot currently until it is voted in. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
Den søn. 7. jun. 2020 kl. 12.18 skrev Deleu : > > What if Nikita changes the RFC to target PHP 8.1 but proceed with voting > now? If voting passes, the RFC will be pending implementation and the > "news" will start to spread. Brandt will write about it in his blog, Reddit > will have a post about it, etc. and the community will start to spread the > information. > Maybe even include 3-way voting and let people decide which version to > target. > > I'm still on the fence whether I like or dislike depredations coming on > 8.1, but my guess is that by carring on with the RFC now the information > will be spread and people will know about it. The question is, why is it important to delay deprecations when they can safely be ignored, functionality will remain the same anyway so it is only a problem for those whose development environments enable E_DEPRECATED in error_reporting. If Symfony (or any other project for the matter) wants to to have no deprecation warnings but cannot make the date for PHP 8.0.0's release, then they shouldn't target PHP8 and we should not delay our process due to that. Either way the changes proposed by this RFC is relatively small and the potential candidate that could hold some projects back (which I hope not), is the accessing static members on traits part, but likely minimal. By the time 8.1.0 is on the horizon, the list of potential deprecations could have doubled. It is important to have php.net be the source of truth for everything, so the official word on deprecations should come in the form of the documentation at php.net and the warnings emitted from php-src. We should not rely on others posting about these deprecations before they happen, everything and nothing can change in between now and when it is eventually implemented. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
Den søn. 7. jun. 2020 kl. 05.58 skrev Theodore Brown : > So while I understand the desire to make upgrades as easy as possible, > I'm not convinced it's a good idea to delay these deprecations for > a later release. At the very least if deprecation is likely the PHP > manual should say something about it. I agree with this and feel very strongly about it, we should not delay deprecations since they can be disabled on a configuration level by removing the E_DEPRECATED bits from error_reporting anyway. Allowing our users to know at the earliest possible moment when something is going to be deprecated allows userland to have a larger time for upgrading as these warnings about certain behavior will change many years from now, but old behavior is still in effect. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DECLINED] match expression RFC
Hi Den søn. 17. maj 2020 kl. 23.01 skrev Ilija Tovilo : > > Hi Jakob > > > If you're sure you're not going to pursue one of these options, maybe > > let us know, so someone else can give it a go based on your excellent > > work and while it's still fresh :-) > > I'm working on a second draft with the following changes: > > 1. Blocks were removed > 2. Secondary votes were removed > 3. Proposal was simplified (roughly 60% was removed) > 4. Discussion period will stay open for longer > > I will announce v2 of the RFC in a few days. Resurrecting rejected RFCs have a "cooldown" of 6 months: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals Whether or not your new RFC qualifies for the second part of this is rule, I can't tell as its left vaguely defined and I can't recall it being used besides the scalar type hints RFCs. Perhaps someone smarter than me can phrase this better. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RESULT] Re: [PHP-DEV] [VOTE] Round two, PHP 8.0 RM
Den tir. 5. maj 2020 kl. 21.05 skrev Sara Golemon : > I assume you're already familiar with > https://github.com/php/php-src/blob/master/docs/release-process.md as our > official process documentation. > > I'd also like to point you at https://github.com/sgolemon/php-release > (prebuilt > on docerhub as sgolemon/php-release ). It does a LOT of the work described > under "rolling a release" in an automated and easy to recreate fashion. I > invite you to do a trial run making an "alpha0" and uploading it to > downloads.php.net/~gabrielcaruso (Derick or someone will reach out shortly > on setting up an account and how to reach that server). > > Also, don't forget to add your GPG key to > https://github.com/php/web-php/blob/master/include/gpg-keys.inc > > -Sara I just granted the web karma and relevant RM karma (git wise) so he should be able to push his key now. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8.0 Release Manager Selection
Den tor. 19. mar. 2020 kl. 20.16 skrev Ben Ramsey : > I am throwing my name in the hat for consideration as one of the PHP 8.0 > release managers. > > I’ve interacted with many of you through the PHP project and the greater PHP > community for the better part of 17 years. I am by no means a C guru, but I > do have a good working knowledge of the internals, and I like to think I have > a good pulse on the community and a good relationship with many of the > previous release managers. I have experience developing and maintaining > releases for other OSS software projects, and I would love the opportunity to > volunteer more of my time to the PHP project. > > Thank you for the consideration! +1 for Ben -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Capturing reasons for votes for historical sake?
Den tor. 19. mar. 2020 kl. 10.41 skrev Mark Randall : > How is the RFC author expected to document the reasons people are voting > no, if those voting against do not take the time to give even a brief > explanation of why they did so either prior to the vote during the > discussion period, or as part of voting? > > An unexplained "no" vote carries just as much weight as a yes vote, > while being demonstrably less valuable to the community. At least when > voting "yes" you're basically saying you agree with the arguments made > in favour as presented by the RFC. That fully depends on the topic in question. We have a lot of people who are voting thats not actively involved with the core development of the language itself from a code perspective. This means that also any random voter that just votes yes causes additional work on the hands of the active code maintainers. I think last year's vote on the JIT here is a great example of the complexity that I think a very low percentage of the voters in favor understands. Why are we only attempting to harvest the negative thoughts (with the word negative chosen carefully here as voting "No" is seemingly an offense to some), why do we not also record why a feature was voted in? Take the recent Stringable interface RFC, now we have one special interface that is magically added but only for objects containing __toString(). A valid question (to me at least, given I voted against it) would be why we would want this almost seemingly random magic to occur but only for this one instance. Since no such data is recorded either, I can only assume that this is acceptable to most. My point here is that it does both ways. If you wish to hold a survey for such fair enough, but I do not want such to bloat RFCs so that it morally questions my choices when I vote in the sense that I think is best suited. I understand the curiosity but I do not wish for us to fall so deep because someone on Reddit or what not believes anyone who votes against something has to be pulled in for questioning. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Capturing reasons for votes for historical sake?
Den man. 16. mar. 2020 kl. 20.29 skrev Mike Schinkel : > > Hi all, > > Seeing people referencing former RFCs that failed when someone brings up an > RFC (which is a good thing to reference, BTW) I am finally compelled to > comment in hope there would be will to improve it. > > When court justices rule on important decisions they write opinions, or join > with the majority or minority opinion. That way judges and others in the > future can know why things were decided a certain way. > > However in PHP we have no way of knowing why people voted against a proposal > except maybe for those very few who commented negatively on the mailing list. > Which is far from concise and frequently not conclusive. > > It is a real shame that the PHP voting process has no way to capture a > concise description of why people voted against an RFC. A "No" vote could > mean any of the following, or something completely different, and their > reasons are really important when it comes to future consideration of the > same issue: > > 1. I hate the idea and never want to see it in PHP > 2. I'm okay with the idea but > a. I have a small issue with "x" > b. I have a big issue with "y" > c. I prefer to see it implemented using "z" approach instead > 3. I love the idea but > a. Can't support it given "x" > b. I want it to be implement using "y" approach instead > 4. We can't do this until we do "x" first > 5. We should do "x" instead > 6. Or who knows what other reason? > > Would it be possible to add a feature when voting were people either need to > type in a one to two sentence reason why they voted "no" on a proposal OR > select from the reasons that others have already given when voting down the > specific RFC? > > If we had that we could list the reasons and the number of votes that choose > those reasons on the RFC for historical purposes. I am not gonna personally answer a survey everytime I vote against a feature. This is why we have a discussion period to raise issues, of course not everyone will raise all their concerns to each and every RFC (me included, take the annotation RFCS posted over the years, they are awesome but the one thing I dislike is the syntax). I doubt everyone have time to go in details and understand to the teeth what each and every feature does. I instead recommend that you look at Dan Ackroyd's repository which he linked in his reply. Similar to him, I'm also fairly against the development of such a feature. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] get_debug_type
Den man. 17. feb. 2020 kl. 01.25 skrev Mike Schinkel : > Though still not exactly sure where you are headed with it since there are > few detailed and no code examples the first name that comes to mind for me > would be get_real_type(). "real" is a type in PHP (tho we are phasing that out, see is_real() and the (real)-cast), so that name would most likely make it more confusing to userland. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Wiki RFC karma
Den man. 13. jan. 2020 kl. 18.50 skrev Christoph M. Becker : > That would require a php.net account first, for which you can apply via > <https://www.php.net/git-php.php>. I'm not a fan of this, especially considering the nightmare that the proposal to add special voting rights for FIG members and what not, once one start creeps in, everyone will. If the contributor in question wanted to be active at the PHP project, then I see no problem in it -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow ::class on objects
Den tor. 9. jan. 2020 kl. 23.30 skrev Mike Schinkel : > > > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel : > > > > Traits are compiler assisted code copy/paste and not contracts (unlike > > interfaces), so there is no gain in having ::trait. > > It can already be referring to using ::class so it makes little sense to > disallow ::trait unless there is a different reason not to add another > ::keyword. It is not about adding a new keyword; the keyword "trait" already exists and "::trait" is a combination of an operator and an already existing keyword (since we are educating each other). I cannot see any benefits to adding the ::trait syntax (nor the ::interface) one besides some OCD issue that you are using ::class on an instance or name of something that technically is not a class, like in your below example, even less when ::class already is working. > Traits are symbols, so it is not unreasonable that there would be a way to > access it symbolically so that the reference can be type checked. That is where you are wrong, traits are not contracts, so therefore they are not types. You cannot check that a class reuses a trait or not when it is constructed because it is compiler assisted copy/paste. They are a useless symbol to refer to in the context of ::class. I can understand you wish to make a helpful error message to a developer who fails to write a class that is loadable by your runtime, but in your example you are still refering to the trait as it was a type, which it technically isn't. > > One of my use-cases for referring to traits is to provide helpful hints in > error messages, i.e.: > > printf( '%s does not implement %s. You can easily implement that interface by > using %s', > get_class( $this ), > Interfaces\Foo::interface, > Traits\Foo::trait, > ); > > But the instanceof operator does not fulfill my requirements. I manage error > triggering during development and logging during production within the > function. Thus I can just use the implements_interface() function to handle > errors automatically when I am testing an assertion vs. using it just for > branching. > > You'll note I explicitly included a third parameter `$trigger_error = true` > in hopes people would notice, realize what I was doing and not think that I > needed to be educated on the existence of instanceof. That is fine if the instanceof operator does not do it for you, but you could have left that last part of the comment out of the mail, after all, it was just a tip. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow ::class on objects
Moi
Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel :
>
> > On Jan 9, 2020, at 3:29 PM, Ralph Schindler
> > wrote:How would you get the right semantics out of $object::interface, or
> > $object::trait, and/or do you have an example of what you're expecting?
>
> Sorry, I was only thinking about using it on Interface and Trait names, not
> on objects.
Traits are compiler assisted code copy/paste and not contracts (unlike
interfaces), so there is no gain in having ::trait.
> I have a lot of code that looks like this:
>
> use Interfaces;
> if ( ! implements_interface( $object, Interfaces\MyInterface::class,
> $trigger_error = true )) {
>return;
> }
>
> And it feels wrong. I would love to be able to use ::interface, i.e.:
>
> use Interfaces;
> if ( implements_interface( $object, Interfaces\MyInterface::interface,
> $trigger_error = true )) {
>return;
> }
If your $object variable is an actual instance, you can use the
instanceof operator, it treats the right operand as a first class
citizen and allows you to skip writing ::class:
use Interfaces;
if(!$object instanceof Interfaces\MyInterface)
{
// Notice the ! is right associative and instanceof is non
associative, hence the lack of parantheses
}
use Interfaces;
if($object instanceof Interfaces\MyInterface)
{
}
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
Den tor. 19. sep. 2019 kl. 20.38 skrev Chase Peeler : > 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? 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. 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. 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. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Defining the PHP Group
Hi Joe Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins : > > Morning internals, > > There is confusion among the community, and contained in the documented > history of PHP on the wider internet. > > The Wikipedia states that PHP is developed by the PHP Group, in saying this > it is (must be) referring to internals as a whole, but our own > documentation names members of the group - who aren't even around mostly. > > I think we need to clarify what exactly is the purpose of the PHP Group > today, does anyone want to attempt to do that ? This is speculation/my interpretation, so take this with a grain of salt; I think The PHP Group was the project governance back in the day, but with PHP's ever so vastness and expansion, new developers come in, old developers go all the time, I don't think this ever got to be what it was meant to be. Now a days it mostly seems to serve as a legacy of the past. Given the recent clarification from Rasmus, I do not think the name has any meaning anymore besides being a fancy name that holds the copyright, whereas the copyright probably should be updated to be: "Copyright (C) The PHP Project", on the PHP.net website, license et al. Besides this I cannot think of a place where I have seen a definition of "The PHP Group" or seen it active besides its recent mention of being an "authoritative" power (which clearly is not the case as there is no legal ramification to hold this statement true). (I picked "The PHP Project" over "The PHP Development Team" which is also commonly used to include everyone who contributes time and resources to PHP). > Whatever it's purpose, if it has one, we need to make clear at this time > that there are no vetos: As Rasmus clarified, PHP is driven by the people > who write PHP: No member of any group or company, historical or otherwise, > has any veto powers, they cannot, and they must not behave as if they do. > > I would like to update the introduction to the Voting RFC: > > The development of PHP is community driven by the RFC process described in > this document. Anyone may initiate an RFC for any subject. At the end of > the RFC process a vote is held among PHP developers to determine if the > proposal is to be accepted. > > Should a proposal be accepted, the developers of PHP are committed to > making the change. > > In some circumstances, merging an implementation into the source code of > PHP may be delayed because of shortcomings in that implementation. In these > cases, resolution of these shortcomings is the responsibility of the > proposer. > > Should a proposal be accepted without an implementation, it is the > responsibility of the proposer to provide one. > > Does anyone object to any of those words ? > > Do we need to vote on changing the introduction (I'm happy to start an rfc > for this, if necessary) ? I got no objection to adding it, but perhaps an RFC should be more in the direction of a "Mission statement" of sorts, stating what the project is, what our goals are, who steers the direction etc. This could be a decent start to sorting out the strings. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Den tir. 10. sep. 2019 kl. 13.14 skrev Rowan Tommins : > That's a reasonable point; that (and the inverse: governments blocking > access to github in response to some perceived offence) would be a > potential issue to weigh up against the risks of running our own > infrastructure. We are already under the US law when it comes to distribution of software as our binaries (like Windows) which contains encryption software for export since we potentially allow countries which the US have an embargo with, such as Iran (or more recently Venezuela). If I remember correctly its partly the reason why PHP is registered as an entity in the US to comply with EAR. How this is dealt with under the hood of the project and all of that I have no idea, but even as it is, we are not currently operating in a noman's land and already live with restrictions imposed by the governments of the world. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)
Den tor. 5. sep. 2019 kl. 13.22 skrev Côme Chilliet : > Because the PHP project should avoid depending on a privately owned > centralized service for its technical discussions, and should not encourage > (some would say force) people to use such platforms. > > PHP is already on github but it’s only a mirror, the main git repository is > at git.php.net . As an old timer around here, I feel very strongly about moving the medium and I prefer to be on the PHP.net infrastructure. Clearly one of our biggest issues with that as the PHP organization is that we poorly maintain it, and I think it could be time to rather invest into renewing that effort instead. It seems like many have an issue with subscribing to internals (I know it was broken for the longest time by using the webform), but that is something we can telegraph better on the php.net website for one thing and try to put resources into figuring this problem out to gain momentum for more developers to join the effort of internals development. Using Github for PRs and relevant discussions for that is perfectly fine with me, but switching to Github for RFCs is a big -1 from me, it is really difficult to read new comments if you are not email subscribed and even then it still remains hard to follow. The individual moderation required to also sort out irrelevant comments is also one thing I personally would not want to deal with either. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)
Den fre. 6. sep. 2019 kl. 08.33 skrev Mike Schinkel : > > Hi Kalle, > > Thank you so much for your feedback. > > > I am not sure of the list etiquette. Should I respond to all your points > here and possibly generate a lot of emails, or ask that we move the comments > to my Gist? You are welcome to reply both here and in the gist for your readers which may not be reading internals, thank you :) -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)
Hi Den fre. 6. sep. 2019 kl. 07.22 skrev Mike Schinkel : > Thank you very much for your feedback. You illustrated perfectly why I > should not have produced that proposal in haste. > > Your confusion was due to my first draft errors, which thanks to your > feedback I have hopefully had a chance to correct. I effectively rewrote and > extended the proposal which you should be able to find at the same URL: > > https://gist.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117 > <https://gist.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117> > > I would be greatly appreciative if you could give is a second look. > > > > All in all I do not understand the benefits of this approach compared to > > Nikita’s RFC. > > I have moved the benefits to the beginning of the document and expanded the > list I elaborate on. > > Hopefully they will be clear now? > > > -Mike Schinkel I read both versions of this and it strikes me more as a partical interface that is half baked by using keywords, that is not really in line with how the rest of PHP is designed. This sounds more like something that could be implemented on top of Nikita's RFC if it passes in userland, but anyway, here goes with my comments to this: -- New magical methods that appear out of nowhere without an interface, e.g. ::type(), ::value(), ::setValue(), ::toXZY(). if these magical methods suddenly appear with may be varadic based on the value of the `types` setting, this is inconsistent to the rest of PHP. -- There is no mention of what happens if there is multiple `types` in a definition. -- Why is the syntax using | as a separator where all other decls is using a comma separated list? -- Nitpick The "types" decl doesn't use an ending semicolon in any of your examples -- Nitpick: Your examples in the "Accepting params into a union instance" section uses $this in a procedural function -- In the "Named Union equivalence to anonymous union" section I fail to see how Building2 can magically accept Building, this is based on properties and there is there is no mention of the ability to have (or not to have) multiple named unions as property types. -- Is this designed to be only meant for mutability (You are publically exposing setValue())? -- What happens if the class is extended? -- Why is it desired to implement a namespaced class instance return? If you are working on the object, you should already have access to this information it provides, no? -- Why is ::types() apart of the union instead of leaving that to reflection? No other part of PHP exposes such as a method over procedural functions (like get_object_vars()). (Bear in mind I wrote this as the first in the morning) -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler : > You going to come and fix the issues? It's an internal application and > most of those messages are coming from legacy areas of the code which are > mainly "it works, so leave it alone" things. Instead of going back and > spending time trying to fix those boondoggles, we invest the time of our > developers (there are 2 others besides myself) into building new features > that help our business grow. Time permitting, we try and update some of the > legacy areas, but, we usually find it's a better investment to just rebuild > them at that point. > > Bottom line is that we live with the not-so-good stuff so that we can focus > on adding new great stuff. The not-so-good stuff isn't holding us back, and > trying to fix things like undeclared variables would have absolutely ZERO > positive effect on our business, which uses this application every day. If > I went to our executive team and said "Can we delay that new scheduling > system that will really help our business so I can go back and update code > to get rid of these undeclared variable notices?" I'd get laughed at! > > Like I've said before - can we please stop pretending we understand > everyone else's situation? Maybe my situation is unique. My gut tells me it > might be unique among people on this list, but, that it's actually pretty > common among the myriad of developers out there which never get involved in > these discussions. I'm sorry, but like Mark Randall has already pointed out then this is a classic example of technical depth. At one point you must choose, "Do I want to upgrade to the latest version of PHP or do I want to fix the issues which is caused by the technical depth in my stack?". I get it, writing new code is always more fun, it really is, I have previously worked with companies with that same attitude that "we'll fix it later", but at one point that becomes such a burden and if your management doesn't believe in putting in resources to actual maintenance of your infrastructure, then I'm sorry but it does not sound like a healthy place to be (no offense meant). Right now your argument is merely trying to hold back changes which will bite that technical depth of yours, and everytime an argument has been raised towards your concerns it has been met with "Will you come and fix it?", "I demand that X, Y or Z tool is available for me to use", etc., so again, I'm sorry but I'm not buying this argument. Some things we can solve by an opt-in, like the strict_types declare, however other things so fundamental to the language should not have any options to alter its behavior, that should be consistent. We have spend a long time trying to carve a migration path and advocate against options which changes language behavior across installations. If we continue down this path, then its just a runtime version of php.ini with a million declare statements on top of each file, each having multiple meanings and an added complexity to maintain the code, not a burden I think userland developers need as it is. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write
Den lør. 29. jun. 2019 kl. 00.02 skrev Wes : > > Hello PHP, > > I just started the vote on > https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write > and I will close it in one week from now The RFC was posted 8 days ago and you need to wait another 6 days before putting this to a vote, please put it back to discussion and read the voting RFC: https://wiki.php.net/rfc/voting#discussion_period Besides this, voting must happen over a 2 week period: https://wiki.php.net/rfc/voting#voting -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for 7.4
Hi Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev : > My first question for many of those is - why? I.e. it deprecates a bunch > of niche functions. Most people do not use these functions, so they > probably don't care. Those they do use them would find their code broken > or produce new warnings and needs to be changed. I have hard time > identifying whose life would be made better by these changes. > > Now, if some of these functions are hopelessly broken or have no valid > use cases - like magic quotes - then phasing them out makes sense, and > the audience whose life can be made better are people who use those > unaware of them being broken, or plan to use them and would thus have > broken code unless we warn them (or remove the functions, eventually). > > But for functions that work just fine, I see absolutely no reason to > introduce friction without any apparent upside. While I understand where you are coming from on this, I do think that functionality that is better supported by dedicated extensions to do the job instead of providing some functions in the standard library that converts from a few specific encodings to another: convert_cyr_string() -- This uses a non standard set of encoding names and only for cyrillic like encodings, what justifications is there for keeping this in the standard library over using ext/intl with UConverter that supports a much larger set of encodings in a much more generic way for more than just cyrillic encodings? hebrev(), hebrevc() -- These functions were designed for the web era pre IE6 where some browsers did not support , what use case is there for these now that the web has evolved so much in the past two decades since these were added to do this on a backend? One of the biggest complaints we have in regards to the standard library is that it is inconsistent, it provides very niche functionality that is better supported elsewhere. I think it is a perfect opportunity to review these legacy blocks and direct users to better alternatives instead of us having to support many ways of doing the same thing. Why should the standard library support only a subset of conversion functionality that is so niche and already supported much more fluently and abstract in extensions dedicated for the matter. I personally think that is a very valid reason to consider these functions for deprecations. We have a large set of aliases that easily can make the standard library feel convoluted and therefore also creates a certain technical depth as a side-effect. The cost of having to convert these functions is a small price to allow the language to evolve in my honest opinion. > For the specifics, I think things like removing allow_url_include > requires separate RFC. It's a serious functionality change, and bundling > it with 20 or so other changes would not allow to properly consider it. > In general mass-change RFCs usually are not very conductive to properly > discussing each specific change, but mixing changes of different types > makes it even worse. I will have a chat with Nikita regarding this. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Deprecations for 7.4
Greetings Internals Nikita and I would like to open the discussion for the RFC: "Deprecations for 7.4", this RFC targets a larger set of various features targeting for deprecation in 7.4 with the intention of removal in PHP 8.0. https://wiki.php.net/rfc/deprecations_php_7_4 If there is no major objections to this RFC, then voting will begin in a 2 weeks time. Regards, Nikita & Kalle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
Den søn. 16. jun. 2019 kl. 02.48 skrev Wes :
>
> Hi Kalle. I hope it's feasible. Unfortunately I don't know much about
> internals. Any info on the matter would be very appreciated, though :P
>
> Anyway, if we can scan the function body to complain about `return null;`
> when the function is `:void`, surely we can scan just the very top of the
> function body to read the imports :P
The latter is detected at a different stage, we can detect some type
errors during the language parser phase, for your example if the
prototype of the function/method has a return type set to void, then
any return statements within the body causes an error, while most
other errors happens at runtime:
function invalid() : string {
return null;
}
Will first throw an error the moment it is called, not when it is
parsed unlike your example.
The problem here is that you cannot perform that binding of a variable
until the runtime kicks in (you don't know if $a exists until you
attempt at binding it which must be at the time the closure is
created, not when executed from an engine perspective).
(Also, regarding the other email you sent to Moe, please keep this
language and such comments off the list and in private, such does not
belong to internals, it is a mailing list about the development of a
programming language, not a kinder garden)
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
Hi
Den søn. 16. jun. 2019 kl. 01.37 skrev Wes :
>
> Hi Kalle, I realize it's going to be a bit odd when binding by value. But
> it's not that hard to grasp.
>
> ```
> $a = 123;
> $closure = function(){
> use $a;
> echo $a; // 123
> };
> $a = 345;
> ```
Take this example:
function get_closure() {
$a = 123;
return function() {
use $a;
echo $a;
};
}
get_closure()();
$a is not available at this time because the scope of which $a exists
in is destroyed at this point, which is why it exists as apart of the
prototype like I mentioned and therefore it can be captured.
Your idea means we need to scan the body of the declared closure for
use statements to perform the binding at this stage, adding extra
specialized steps in the executor for only makes me question the
motive for this again, and if the motive is that "I'm passing an
excessive amount of values to a closure", then I think you are forcing
a technique that isn't mean for this to do it anyway. Another thing to
take into consideration here is the performance impact that it can
potentially have.
Whether or not its at the top of the body or separated in multiple
statements or all over the body still means we need to check if the
body contains such a statement and do the right computations for it, I
still don't think the argument presented in the RFC justifies this
potential cost, and would like to see a demo implementation and impact
it would have first.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
Den søn. 16. jun. 2019 kl. 01.09 skrev Wes : > > Declaring variables or specifying which ones to import. Essentially it's > the same thing, so what gives? It's PHP's syntax, IMHO, that makes the > thing irritating to write :D The proposed syntax was also that of the proposed syntax when closures arrived in 5.3 (and back then it was using the then keyword 'lexical'), anyway. I believe the current syntax was chosen due to scopes, as values are bound specifically when the closure is created and not when the closure is executed. For example if you have a function that returns a closure and the closure imports a variable local to that and then later call it from a different scope, that means we need to keep that old scope alive until then which can be rather problematic, instead it was decided back then to have the import of parent scope variables as apart of the prototype as it is possible to capture the value in the Engine at this point in time. I agree its odd but I would much rather keep the current implementation. Also in regards to the RFC, if you have massive argument lists like in the RFC then I think you should re-think your design and put such complex computations into separate methods which also encourages better testability. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Changing the default value of SQLite3::enableExceptions()
Hi Christoph
Den lør. 18. maj 2019 kl. 13.00 skrev Christoph M. Becker :
> However, I don't think that we can change the default value in the near
> future for BC reasons. Deprecating (7.4) and removing support (8.0) for
> calling the method without argument would be the way to go, I think.
Yeah I agree here. We could go a similar around to what you proposed
for the curl version function, something like (for PHP-7.4):
if (ZEND_NUM_ARGS() == 0) {
/* E_DEPRECATED: Relying on the default value of $enableExceptions
is deprecated as it will change from FALSE to TRUE ...*/
}
And for master simply making the parameter required. I suspect the
impact of this is very minimal as most users of this would not be
affected by this proposal unless its a bug in their code (as I don't
expect anyone to call ->enableExceptions() to *disable* them being
anything but a bug).
> [In a somewhat distant future, we might consider reintroducing support
> for argument-less calls, but in this case it might make sense to let the
> method work as getter (i.e. without argument, it would return the
> current value without changing it).]
Currently SQLite3::enableExceptions() will return the old value, I
think we should retain this and only change the default value.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing the default value of SQLite3::enableExceptions()
Hi Den fre. 17. maj 2019 kl. 23.20 skrev Robert Kopack : > > I feel like changing the default value of $enableExceptions to TRUE > makes more sense since that is what you would expect from the original > function call as it stands and is the least breakage of anything > already existing (since making it a required variable would throw > ArgumentCountError for any existing code). > > WRT the PR you mentioned (since it's my own), do you think it would be > better to change the current toggleExtendedResultCodes to > enableExtendedResultCodes and have a similar function prototype to > enableExceptions? I didn't consider that when I wrote my changes (to > be honest I don't use the sqlite3 class directly so I didn't know > about it, I only used the pdo_sqlite layer above it). I thought about proposing that, but I wanted to run this issue by internals first to hear others thoughts on the matter. I definitely think consistency is something we should embrace more and thinking about it for a day then I do think we should keep the naming similar, but avoid a design like SQLite3::enableExceptions(). -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: MODERATE spam
Den lør. 18. maj 2019 kl. 20.19 skrev M. W. Moe : > > Hello, > > didn't get any; should ask over folks; I suspect it originates from a > frustrated individual > which didn't found anything else smarter than spams to achieve his pity > vendetta. > > Did you kept the original ones? > > tschüss. These mails only goes to moderators of the php-announce@ list, typically RMs and the like moderates this list hence why only a handful has gotten them, each moderation mail contains the original mail and addresses to approve or reject the message. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Changing the default value of SQLite3::enableExceptions()
Evening Internals While reviewing a PR[1], which proposes to add two new methods to ext/sqlite3, one being an option to toggle on/off, I've noticed that there already is another method which also enables the extension to toggle on/off behavior, in this case; whether or not to throw exceptions instead of warnings. This method have a rather poor naming considering its default value. Observe the current prototype: SQLite3::enableExceptions ([ bool $enableExceptions = FALSE ] ) : bool What this means is that code like this may not do what you actually think it does: $link->enableExceptions(); Due to the $enableExceptions parameter being default to false. I'm writing this email to get some feedback on thoughts regarding changing this default value to true (current thinking is PHP8) or simply dropping the default value, forcing users to specify whether or not to enable exception mode. I personally think its better to simply deal with the default value rather than making a bigger potential BC break by renaming the method to something like: SQLite3::toggleExceptions() Thoughts? [1] https://github.com/php/php-src/pull/4166 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for a RFC
Hi Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade : > > Hi Internals team! > > I have an idea for a feature that I'd love to see in the language one day and > wanted to run the idea by you all. > > The idea is to add a new magic method "__toArray()" that would allow a > developer to specifiy how a class is cast to an array. The idea is the same > mentality of __toString(), but, for arrays. While this sounds great and all, I do wonder about the implications it may have on the already existing behavior of type casting an object into an array which returns current public/protected/private property values. While this functionality is not an ideal or by design, it is fairly heavily (ab-)used, meaning that it is a potential BC break without the ability to an alternative. See this example: https://3v4l.org/ONMoi -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for a RFC
> I find it easy to imagine that objects not implementing __toArray() would > continue to exhibit that behavior. Obviously. So what about code that operates on this behavior, should that then suddenly break if the object implements an __toArray() method? That sounds wrong to me -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Christoph Den lør. 4. maj 2019 kl. 14.19 skrev Christoph M. Becker : > > On 04.05.2019 at 10:56, Christoph M. Becker wrote: > > > I have submitted PR #4112 to bring back the common PDO tests, which are > > the majority of existing tests for pdo_firebird. Three tests are > > failing (which should be investigated), but these tests already failed > > in PHP-7.3 and maybe before. I had a look at your PRs, both look good! Like I mentioned on the common.phpt one, I wasn't aware of this PDO magic, so its good that you fixed it quickly. +1 on both PRs. > I had a closer look at the tests failing with Firebird 3.0.4.33054 (x64): > > bug_69356.phpt fails because FB doesn't support `SELECT expr;` queries; > apparently, a FROM clause would be required. If that is the case, we should add the FROM clause. When I tested it, it was passing but I'm uncertain how exactly. I was using a 3.0.2 x64 build on Windows for these, so there seems to be something odd going on here. > bug_71447.phpt fails because there are issues regarding comments with a > single quote. Could this be an SQL dialect setting missing given its pass for me? > bug_73234.phpt fails because FB doesn't support defining explicit > nullable columns, i.e. > > CREATE TABLE (id INT NULL) > > is unsupported. Removing the NULL let's the test proceed, but binding a > zero as PDO::PARAM_NULL apparently inserts `string(1) "0"` which looks > like a bug in the driver. Again odd it did not fail for me, but we should log a bug about this issue if there isn't one already and hope that someone will pick it up unless you want to invest the time into it. Thanks for looking into these! Much appreciated. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Christoph Den fre. 3. maj 2019 kl. 12.02 skrev Christoph M. Becker : > While running the tests with a PHP debug version, I've noticed that > bug_aaa.phpt is causing a memory leak. Maybe someone proficient with > Firebird/Interbase will want to have a look at it. Thank you for testing, good to know that they at least run there too! As for the memory leak, perhaps we should mark the relevant test with an --XFAIL-- or something? The name was suspicious in the first place. Guess this is as good as it gets for PDO_Firebird at least. I can see the PR regarding adding boolean types to PDO_Firebird was updated too, to reflect these changes so it should be good to go into 7.4 I suppose if its rebased. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Den tor. 2. maj 2019 kl. 22.55 skrev Lester : > The problem with including a database is it's dependent on the version > of FB running. This will only run with FB3 while FB2.x is still in > common use hence it being preferable to use something supplied with the > FB installation. > > https://firebirdsql.org/manual/qsg10-connecting.html For Windows at least, we only support Firebird3 with the binary-sdk, I don't know about Unix. However I updated my patch, see this for more info: http://git.php.net/?p=php-src.git;a=commitdiff;h=1c893b89bdb2b8bd5608c14cd0930727db6ba409 If a brave soul can test on Unix it would be great, but this is about as good as it gets. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Christoph Den tor. 2. maj 2019 kl. 16.57 skrev Christoph M. Becker : > > Hi Kalle, > > On 02.05.2019 at 15:35, Kalle Sommer Nielsen wrote: > Indeed, it seems that pdo_firebird requires to connect to an existing > database, contrary to e.g. pdo_mysql which supports DSN like > `mysql:host=localhost`, to my knowledge. But even if pdo_firebird has > been connected to an existing database, it appears that it's not > possible to create a new database via PDO (I got something like "prepare > does not support CREATE DATABASE", even with emulated prepares turned on). Please check this commit: http://git.php.net/?p=php-src.git;a=commitdiff;h=c9599c1c726e3bce8ce5a80c1ac8ee2c81bffb61 It also includes a 'php.fdb', which I'm not certain whether or not we should keep as its quite large, but at least it makes the tests run for me with 15/15 pass. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Christoph Den tor. 2. maj 2019 kl. 14.56 skrev Christoph M. Becker : > A problem is that the ext/pdo_firebird tests rely on ext/interbase to > create a test database[1], which would require everybody who intends to > run these tests to install PECL/interbase package now. It would be > great if somebody would rewrite this, so interbase would no longer be a > dependency of the pdo_firebird tests. > > [1] <https://github.com/php/php-src/blob/PHP-7.4/ext/pdo_firebird/tests > /testdb.inc> Yeah that is one thing that is kind of unfortunate and a bad practice. However since interbase was disabled for AppVeyor, these tests had no chance to run in a while. Looking at the actual code in testdb.inc, it seems like it creates the database for testing purposes, I would suppose this is due to PDO_Firebird perhaps requiring a database to continue its connection flow in PDO itself. I'm not sure how we can go about this, maybe a .sql file for testers who run the test suite for schemas and then see if we can integrate some auto importer in our CI build scripts for this special case? (In the case we cannot go around PDO). Either way the test files requires a manual touch to configure credentials to run. I'm personally fine with the simple solution, thoughts? (ps. Thanks for the fix for the AppVeyor part I missed) -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Den tir. 9. apr. 2019 kl. 20.02 skrev Kalle Sommer Nielsen : > > Evening Internals > > Apologies for the one day delay, but the voting for the RFC "Unbundle > ext/interbase" is open[1]. There is only one voting choice, which > decides if the extension should be moved to PECL. > > Since this started a day later than anticipated, then the voting will > naturally run for one extra day and therefore officially close on > tuesday, 23th of April, 2019 around noon EET. > > > [1] https://wiki.php.net/start#voting The two weeks voting period for this RFC has passed and the RFC has been passed with 46-0 in favor. I will prepare relevant practical tasks for this RFC throughout the week. Thanks to everyone who voted. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Hi Den ons. 17. apr. 2019 kl. 09.54 skrev Köditz, Martin : > By the way: > Pierre Joye mentioned to request access via a github account at > https://www.php.net/git-php.php. I read the complete instruction. But I'm > still unable to process successfully. I always get an error saying the answer > is not correct. Surely I'm doing something wrong, but I don't know what. > That's a similar problem as with the subscription form. Please consider to > make it more user friendly. I am sure other people will fail as well. This is the anti spam check (similar to that which you mentioned you were encountering on when attempting to register on the wiki), please read the page *carefully*, namely the table at the top of the page. The reasons for why this check exists is well explained on the page itself. In the last dropdown on this form, please just select "PHP Group" (it really does not matter too much) > What are the next steps? In which area should I register as a maintainer? In > the ext or PECL area? How do I do that and who is my contact person? For PECL, please see the following page[1]. For both the first link and this one, you can mention "Kalle" as sponsor. When both requests are done successfully, then either reply to this thread or make a new one on internals and let's take it from there. There generally is no specific contact persons here at the PHP project, however the lists are always open for questions, some internals people also hang out in external (unofficial) chat rooms and so on, but all official discussion *has* to be done on Internals as a bare minimum (This is extremely important). If the RFC vote passes, then I will try get you inserted as a maintainer for the extension. This is a first for me doing that so digging up the right channels to get it done may take a bit of time. [1] https://pecl.php.net/account-request.php -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
case the vote passes when it ends in about a weeks time. That is for the Firebird Foundation to take over control of the extension on PECL and work out its problems and re-propose it to be included back into php-src once it is in a mature state with the PHP RFC process. This means that it still has the possibility of being included in PHP8 which currently is looking to be released at the end of 2020. That leaves over a year to get familiar with how the PHP project works, our policies, community and guidelines. As a personal advice, I strongly advice to invest in the PDO_Firebird extension as PDO is considered the primary way forward for database access in PHP (Yes we have ext/pgsql, ext/mysqli, ext/sqlite and such but they are mature and stable and widely used). Start by making a plan and look at what the current PDO_Firebird driver offers and doesn't and post patches through Pull Requests and they will most likely be merged fairly quickly. However if nothing happens with the PDO_Firebird driver, then I could potentially seeing it joining PECL in the future as I'm unfamiliar its internals, but looking at the bugs reported[1], I can only start wondering. [1] https://bugs.php.net/search.php?cmd=display_type=All=Open_name%5B%5D=PDO+Firebird=Any=30 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Den tir. 16. apr. 2019 kl. 20.09 skrev Lester Caine : > The 'advantage' up to now of being in core has been that the BULK of the > code changes have been required to track changes in the PHP side of the > interface. The core SQL interface has not basically changed so up until > now it has worked fine for both Firebird and Interbase. So as long as > someone who understands the PHP side of the equation puts the same > generic changes into the driver as in other core extensions then things > carry on working ... but developments in the PHP side have become a lot > more difficult to track than when I did manage to apply fixes to the > driver code many years ago. Everytime the topic of interbase comes up, you always referer to applying fixes, yet I'm yet to see any contributions from you to actually maintain the code at php-src, am I to understand that this means you patch your own builds of PHP? Because it is not something that strengths the argument that has any merit of strengthen the argument of keeping it, quite the contrary if anything. > Moving forward there has been some substantial changes on both the > Firebird and Interbase side which today could benefit from a separation > but that is not 'essential' to continue to use the the legacy interfaces > as the vast majority of development work on the Firebird side is in > additional SQL functionality and the core way of passing that has not > changed in 25 years so there has been no reason to 'continually update' > the driver, only the wrappers around the basic driver. Which do not > impact the driver extension itself? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP (ext/interbase) driver maintenance
message text=== Hello Helen, > > hope everything is running smoothly in the Southern hemisphere ;-) > > I would like to give you an update on . The voting to exclude the > driver from the main php distribution has started (only people on the > php.internals mailing list can vote, http://news.php.net/php.internals) and > as expected it is not looking good: > > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase > > Today Martin has finally succeeded to get into the internal php-mailing > list, after he had contacted some guys of the core php team directly. Let's > see ... > > best, Volker -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Den tir. 9. apr. 2019 kl. 20.02 skrev Kalle Sommer Nielsen : > > Evening Internals > > Apologies for the one day delay, but the voting for the RFC "Unbundle > ext/interbase" is open[1]. There is only one voting choice, which > decides if the extension should be moved to PECL. > > Since this started a day later than anticipated, then the voting will > naturally run for one extra day and therefore officially close on > tuesday, 23th of April, 2019 around noon EET. Apologies for the wrong link, the correct one is: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase#voting -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC VOTE] Unbundle ext/interbase
Evening Internals Apologies for the one day delay, but the voting for the RFC "Unbundle ext/interbase" is open[1]. There is only one voting choice, which decides if the extension should be moved to PECL. Since this started a day later than anticipated, then the voting will naturally run for one extra day and therefore officially close on tuesday, 23th of April, 2019 around noon EET. [1] https://wiki.php.net/start#voting -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
