Re: [PHP-DEV] Future stability of PHP?

Hi On 4/11/23 18:32, Jeffrey Dafoe wrote: I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths. You should be able to enable deprecations in production and then check the type of error within your error handler. If it

[PHP-DEV] [VOTE] Make unserialize() emit a warning for trailing bytes

Hi I just opened the vote for the "Make unserialize() emit a warning for trailing bytes" RFC. The RFC contains a single vote that requires a 2/3 majority to pass. Voting runs 2 weeks until 2023-03-26 08:30 UTC. Please find the following resources for your references: RFC Text: https://wiki.p

Re: [PHP-DEV] [VOTE] Make unserialize() emit a warning for trailing bytes

Hi On 4/12/23 09:59, Tim Düsterhus wrote: Voting runs 2 weeks until 2023-03-26 08:30 UTC. That should have read 2023-**04**-26 08:30 UTC, of course. Apparently I'm living in the past. I apologize for the confusion. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Maili

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

Hello George, Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading > > The existing SPL autoloading

[PHP-DEV] Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

Hello, With this mail I want to do the first step of a RFC: "1. Email internals@lists.php.net to measure reaction to your intended proposal." I'm in the process of using hrtime(true) instead of microtime(true), for this it would be great if REQUEST_TIME_HR would also exist next to REQUEST_TIME an

[PHP-DEV] Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

On Wed, Apr 12, 2023 at 12:01 PM Herbert Groot Jebbink < herb...@groot.jebbink.nl> wrote: > Hello, > > With this mail I want to do the first step of a RFC: "1. Email > internals@lists.php.net to measure reaction to your intended proposal." > > I'm in the process of using hrtime(true) instead of mi

Re: [PHP-DEV] Future stability of PHP?

On Tue, 11 Apr 2023 at 12:24, Sara Golemon wrote: > > I'm saying that the DX for writing extensions is better in other > languages. > > Citation needed. Java's extension API is certainly a hot mess. Python's > is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice > at firs

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas wrote: > > To me, class autoloading is a performance feature. If we didn't care about > performance, we would be fine with eagerly loading a bunch of classes as > e.g. Java does. I think (class) autoloading actually serves two purposes: as you say,

Re: [PHP-DEV] Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

On Wed, 12 Apr 2023 at 11:01, Herbert Groot Jebbink < herb...@groot.jebbink.nl> wrote: > > I'm in the process of using hrtime(true) instead of microtime(true), for > this it would be great if REQUEST_TIME_HR would also exist next to > REQUEST_TIME and REQUEST_TIME_FLOAT Hi :) The idea sounds r

[PHP-DEV] Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

On Wed, 12 Apr 2023 at 11:53, Rowan Tommins wrote: > Should the same approach happen here? e.g. should all three > values be based on hrtime fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not possible, hrtime is not based on the actual time, hrtime can be used to calculate a du

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas wrote: > > I would like to see a similar benchmark with function autoloading enabled. > https://github.com/phpbenchmarks/ Can you point me to where one can tell the benchmark framework to use a custom version of PHP? > One of the big differences you'

[PHP-DEV] Moving PHP internals to GitHub

Hey. PHP currently uses internals@lists.php.net for communication. That includes mostly RFCs (or their votings, or their pre-discussion) and sometimes questions about the implementation or possible bugs. While emailing definitely works, it's not the best UX out there. Here are some immediate flaw

Re: [PHP-DEV] Moving PHP internals to GitHub

FYI: https://externals.io/message/87501#87501 Also: wow, that was 7 years ago?! :O Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/ On Wed, 12 Apr 2023 at 15:53, Alex Wells wrote: > Hey. > > PHP currently uses internals@lists.php.net for communication. That > incl

Re: [PHP-DEV] Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink < herb...@groot.jebbink.nl> wrote: > fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not > possible, hrtime is not based on the actual time, hrtime can be used to > calculate a duration or so, not to retrieve the actual time itse

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 04:52:52PM +0300, Alex Wells wrote: > Based on those issues and PHP, I propose moving the discussions elsewhere - > to some kind of modern platform. Since this is quite a big change in the > processes used, I imagine an RFC would be needed. But before I do that I > want to

Re: [PHP-DEV] Moving PHP internals to GitHub

Am 12.04.2023 um 15:52 schrieb Alex Wells : > PHP currently uses internals@lists.php.net for communication. That includes > mostly RFCs (or their votings, or their pre-discussion) and sometimes > questions about the implementation or possible bugs. > > While emailing definitely works, it's not the

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta wrote: > FYI: https://externals.io/message/87501#87501 > > Also: wow, that was 7 years ago?! :O > Thanks. I've completely missed this while searching for an alike thread :) But as you mentioned, it's been 7 years. Many things and people have changed

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 14:53, Alex Wells wrote: > > Based on those issues and PHP, I propose moving the discussions elsewhere - > to some kind of modern platform. This has been discussed before, many times, so I'll keep this brief and let you find the old discussions. I think "moving to a mod

Re: [PHP-DEV] Moving PHP internals to GitHub

On 12 April 2023 14:52:52 BST, Alex Wells wrote: >What are your thoughts? Not a chance. Also, who are you? cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 5:09 PM Alain D D Williams wrote: > * Archives: already done It is; however, there's no way to categorize it (except for creating even more mailing lists), tag it, mark as resolved, close it or basically do anything other than write a message. > * Not way of editing: j

Re: [PHP-DEV] Moving PHP internals to GitHub

Hey Alex. On 12.04.23 15:52, Alex Wells wrote: Hey. PHP currently uses internals@lists.php.net for communication. That includes mostly RFCs (or their votings, or their pre-discussion) and sometimes questions about the implementation or possible bugs. While emailing definitely works, it's not t

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 5:16 PM Rowan Tommins wrote: > I think "moving to a modern platform" presents a false dichotomy. > > Any move needs to be assessed on both the advantages and disadvantages of > *both* (or all) options, not just what looks new and shiny if we move. > > Some starting points

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 15:22, Alex Wells wrote: > > Well, you can't be replying to each reply you support - I don't think > spamming people with notifications is a good idea. Also on practice, I've > not seen such simple "Agreed" or "+1" kind of replies in the past few > discussions - probably be

Re: [PHP-DEV] Moving PHP internals to GitHub

On 12.04.23 16:12, Alex Wells wrote: On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta wrote: FYI: https://externals.io/message/87501#87501 Also: wow, that was 7 years ago?! :O That was exactly my thought as well... Thanks. I've completely missed this while searching for an alike thread :)

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 16:53, Alex Wells wrote: > Hey. > > PHP currently uses internals@lists.php.net for communication. That > includes > mostly RFCs (or their votings, or their pre-discussion) and sometimes > questions about the implementation or possible bugs. > > While emailing definitely wor

Re: [PHP-DEV] Moving PHP internals to GitHub

Le 12/04/2023 à 16:29, Rowan Tommins a écrit : Reactions are a nice social media feature, but I don't think I've ever seen them used to convey anything particularly meaningful. If I write a comment that gets 3 smily faces, 4 angry faces, one rocket, and one of those weird Japanese fireworks, al

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 6:15 PM Pierre wrote: > That was my 2 cents about all this. Maybe what the thread creator mean > is simply that the PHP development process is kind of hidden in this > list, and it's not that easy to reach or read for people, even when > using https://externals.io/ Pierr

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Tue, 11 Apr 2023 at 18:12, Hans Krentel via internals wrote: > > So I'd love to see some commentary on a `function_alias()` > if now function autoloading is considered to come in I wouldn't be opposed to it, but it should be a separate RFC. The implementation could be copied from https://www.

Re: [PHP-DEV] Future stability of PHP?

On Tue, Apr 11, 2023, 1:30 AM Deleu wrote: > > > I resent the sentiment of "if your code or development process was exactly > like mine you wouldn't be here complaining" and I believe nobody is asking > PHP to freeze. Not everyone has the ability to fix every deprecation within > a couple of hour

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 15:53, Alex Wells wrote: > > Hey. > > PHP currently uses internals@lists.php.net for communication. That includes > mostly RFCs (or their votings, or their pre-discussion) and sometimes > questions about the implementation or possible bugs. > > While emailing definitely work

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 3:53 PM Alex Wells wrote: > What are your thoughts? > I'd simply give you a thumbs up and 100 reaction if I could, but instead I'm giving everyone an unread notification just showing that I 100% agree.

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 4:16 PM Rowan Tommins wrote: > * Ease of access (is subscribing to e-mail *really* harder than logging > into Github?) > Took me over a year and poking people on twitter before my mailing-list sign-up worked, so I'd say that's a yes. I feel like this mailing list is mainl

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Tue, 2023-04-11 at 11:57 +0100, G. P. B. wrote: > No, array_map will trigger the autoloader (actually strlen() will > trigger it once first) and the autoloader should then load the > array_map function from the My namespace. > However, if the autoloader does not correctly load the My\array_map()

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi! - having to subscribe to a mailing list to even see the discussions Not really, there are archives. - having to learn the specific, uncommon rules of replying: bottom If learning a couple of very simple rules is too much for you, maybe you are too busy to take on yourself another

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

> Le 10 avr. 2023 à 14:17, G. P. B. a écrit : > > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.

Re: [PHP-DEV] Moving PHP internals to GitHub

Please no, I want to read e-mails when I want, with my own software, leaving to me the freedom to mark things as important, or read, or unread, or sort them in folders. An important point : not all people in the world have access to the internet at all time. Some people have to fetch the messages

[PHP-DEV] [RFC] Last chance to discuss "Use exceptions by default in SQLite3 extension" before vote

I'm planning to start the vote on this RFC in a week or two. I changed the RFC to only have one proposal: deprecate warnings in PHP 8.3 and switch to exceptions in 9.0. Feedback is welcome :) Thanks to people who have provided feedback previously and on my PRs. https://wiki.php.net/rfc/sqlite3_e

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 7:31 PM Stanislav Malyshev wrote: > If learning a couple of very simple rules is too much for you, maybe you > are too busy to take on yourself another responsibility such as > participating in PHP development. Encouraging drive-by commentary is not > something that is a g

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 16:25, Alex Wells wrote: > On Wed, Apr 12, 2023 at 6:15 PM Pierre wrote: > > > That was my 2 cents about all this. Maybe what the thread creator mean > > is simply that the PHP development process is kind of hidden in this > > list, and it's not that easy to reach or read

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi , You made some good points, but please, avoid including statements that are plainly false: it lessens your arguments. I am specifically thinking of: > - having to subscribe to a mailing list to even see the discussions Have you never heard about externals.io ? > - hav

RE: [PHP-DEV] Moving PHP internals to GitHub

> Oftentimes community discussions are happening in parallel to the internal > discussions on the PHP reddit. > As is the same for this discussion, reading it is often useful to get > community input. > https://old.reddit.com/r/PHP/comments/12jrc8j/the_discussion_on_the_mailing_list_about_moving/

Re: [PHP-DEV] Moving PHP internals to GitHub

Hello, Just dropping my unsolicited 2 cents... A lot of big software development is done via email and not on discussion boards like GitHub. Here are some of the ones I lurk on: - Chrome-dev - Various linux kernel mailing lists - Some random Mozilla one - A NASA one from when I was doing som

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 19:00, Reinis Rozitis wrote: > > Sadly, there isn't anything useful being discussed just some people being > upset about why someone doesn't (immediately) want to move to their > [favorite] platform what gives even more validation for those who are > against it. > > > p.s.

Re: [PHP-DEV] Moving PHP internals to GitHub

On 12/04/2023 19:05, tag Knife wrote: I say this as someone who was trying to onboard themselves the other day (web-php and php-docs). The entire process is archaic and uses "tools" from 20 years ago. Onboarding for anything you're interested in doesn't really give a direction at all (unless you'

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 8:42 PM Rowan Tommins wrote: > > On 12/04/2023 19:05, tag Knife wrote: > > I say this as someone who was trying to onboard themselves the other day > > (web-php and php-docs). > > The entire process is archaic and uses "tools" from 20 years ago. > > Onboarding for anything

Re: [PHP-DEV] Moving PHP internals to GitHub

On 12 April 2023 19:05:56 BST, tag Knife wrote: >On Wed, 12 Apr 2023 at 19:00, Reinis Rozitis wrote: > >> >> Sadly, there isn't anything useful being discussed just some people being >> upset about why someone doesn't (immediately) want to move to their >> [favorite] platform what gives even more

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 19:42, Rowan Tommins wrote: > > Which brings me back to my earlier point: I wonder how much of the > reaction is really about e-mail itself, and how much is just the > documentation and sign-up forms you encounter *before* you hit the list. > Because if it's the latter, mig

Re: [PHP-DEV] Moving PHP internals to GitHub

On 4/12/2023 6:52 AM, Alex Wells wrote: Hey. PHP currently uses internals@lists.php.net for communication. That includes mostly RFCs (or their votings, or their pre-discussion) and sometimes questions about the implementation or possible bugs. What are your thoughts? The subject line reads as

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 22:07, tag Knife wrote: > On Wed, 12 Apr 2023 at 19:42, Rowan Tommins > wrote: > > > > > Which brings me back to my earlier point: I wonder how much of the > > reaction is really about e-mail itself, and how much is just the > > documentation and sign-up forms you encounte

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska wrote: > > > This is the second major mailing list in the past few weeks that I'm on > where this exact topic has arisen. On the other list, the developers of > the project were the ones who proposed it and the idea was universally > and unilaterally

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 20:54, Lynn wrote: > > Was this topic discussed only on the mailing list? Asking mailing list > users if they like the mailing list is obviously going to skew the opinion > into a direction of people being in favor of the mailing list. > I use the mailing list (rarely) to

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 9:54 PM Lynn wrote: > > On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska > wrote: > > > > > > > This is the second major mailing list in the past few weeks that I'm on > > where this exact topic has arisen. On the other list, the developers of > > the project were the ones w

Re: [PHP-DEV] Moving PHP internals to GitHub

On 12/04/2023 20:07, tag Knife wrote: Choosing discussions to take part in, mailing lists are just an all or nothing deal. It depends what you mean by "take part in", I guess. But yes, e-mail forces you to have a local mirror of the active topics to choose from and reply to, which isn't alw

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks wrote: > Here's a question: Who is going to be in charge of maintaining the GitHub > org and administrating it? > As someone who does community management for a long long time, I forsee > someone needing that to be their life for a project of this scal

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi, Interesting discussion I do prefer a good organised forum above a mailinglist: - better overview - better searchable - quicker to read - less mail - possibility to give likes As a newcomer here, it is hard to find previous information. Even on externals.io. That signing on to the mailin

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi!  I'm not sure why it's assumed that participating in discussions is the same as actually developing PHP. I'm sure there are plenty of folks Right. And participating meaningfully requires some level of commitment and investment. For example, willingness to familiarize oneself with some

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 10:14 PM Stanislav Malyshev wrote: > Right. And participating meaningfully requires some level of commitment > and investment. For example, willingness to familiarize oneself with > some very simple rules and follow them. If that's not for you, that's > fine - there are ma

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, 12 Apr 2023 at 23:05, tag Knife wrote: > > > On Wed, 12 Apr 2023 at 20:41, Arvids Godjuks > wrote: > > >> If people want to mirror internals to GitHub and manage it all and then >> feed back the information into the list with links and feedback - >> personally be my guest. But let's get

Re: [PHP-DEV] Moving PHP internals to GitHub

On 12/04/2023 21:19, Lynn wrote: The rules and etiquette are detached from the mailing list, so it's not obvious that they even exist. See https://externals.io/message/119955#119987 The etiquette rules would need to exist even if we moved to a different technology, and fixing the documentat

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On 12/04/2023 17:31, Claude Pache wrote: * keep the current semantics, that using a namespaced or qualified function name, (including a function name given as string, which is implicitly fully qualified), doesn’t fall back to the global scope, — even when a previous use of the same function na

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 2:53 PM Alex Wells wrote: > > Based on those issues and PHP, I propose moving the discussions elsewhere - > to some kind of modern platform. Since this is quite a big change in the > processes used, I imagine an RFC would be needed. But before I do that I > want to measure

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi! I think what could be proposed instead is to enable GitHub discussions for discussing ideas before they are proposed on the mailing list. It could be Don't see any problem with that if somebody would be willing to keep an eye on it and do the moderator duties (unfortunately, any public fo

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023, at 6:42 PM, Rowan Tommins wrote: > Which brings me back to my earlier point: I wonder how much of the > reaction is really about e-mail itself, and how much is just the > documentation and sign-up forms you encounter *before* you hit the list. > Because if it's the latter

Re: [PHP-DEV] Moving PHP internals to GitHub

On Wed, Apr 12, 2023 at 9:37 PM Stanislav Malyshev wrote: > Hi! > > > I think what could be proposed instead is to enable GitHub discussions > for > > discussing ideas before they are proposed on the mailing list. It could > be > > Don't see any problem with that if somebody would be willing to k

Re: [PHP-DEV] Moving PHP internals to GitHub

I love this idea. Although GitHub is not perfect, it would be so much better than a mailing list. Mailings lists are annoying: they have very poor searching capabilities, you can't unsubscribe from a thread you are not interested in, you can't follow the conversation easily because it's not always

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

On Wed, 12 Apr 2023 at 17:32, Claude Pache wrote: > > The proposed modification of `function_exists()` will break existing code: Please can you submit a failing test to https://github.com/Girgias/php-src/tree/zend_autoloader that shows a BC break. cheers Dan Ack -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi On 4/12/23 23:39, Kamil Tekiela wrote: I love this idea. Although GitHub is not perfect, it would be so much better than a mailing list. [...] But unfortunately, if it came to a vote, I would vote NO. The mailing list must remain IMHO. It's terrible and annoying but it's also very simple and

[PHP-DEV] First class callable syntax for instance methods

Hello, internals! I just want to share some thoughts with you regarding what could be improved in the first class callable syntax. It is already possible to create Callable from a static method: ``` class Foo { public static function staticmethod() {} } $c = Foo::staticmethod(...); ``` It would

Re: [PHP-DEV] First class callable syntax for instance methods

On Thu, Apr 13, 2023 at 6:00 AM Eugene Sidelnyk wrote: > > Hello, internals! I just want to share some thoughts with you regarding > what could be improved in the first class callable syntax. > > It is already possible to create Callable from a static method: > > ``` > class Foo { > public static

Re: [PHP-DEV] First class callable syntax for instance methods

On 13 April 2023 04:59:56 BST, Eugene Sidelnyk wrote: >It would be a great pleasure to have the ability to wrap the instance >method the same way. The first-class callable syntax works just fine with instance methods, but you need to use it on a particular instance: $someInstance->someMethod(

Re: [PHP-DEV] Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']

Op wo 12 apr. 2023 16:04 schreef Rowan Tommins : > On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink < > herb...@groot.jebbink.nl> wrote: > >> fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not >> possible, hrtime is not based on the actual time, hrtime can be used to >> calcul