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

[Eugene Sidelnyk]

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 be a great pleasure to have the ability to wrap the instance
method the same way. One particular use case for this could be when there's
an array of items and it is necessary to call some getter-method on all of
them.

```
class Verification
{
public function __construct(private string $id) {}

public function getId(): string
{
return $this->id;
}
}

$items = [new Verification('1-2-3-4')];

array_map(Verification::getId(...), $items);

// previous line is an equivalent of this
array_map(static fn (Verification $v) => $v->getId(), $items);
```

Currently this syntax fails in run-time rather than compile-time.

```
PHP Fatal error:  Uncaught Error: Non-static method Verification::getId()
cannot be called statically in /opt/scratches/scratch_439.php:21
```

Please, let me know what you think about it.

Best regards, Yeven

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

[Tim Düsterhus]

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
ubiquitous. And that's what is needed for inclusivity. A lot of senior
developers prefer this kind of communication method so if we asked them to
switch over we could lose them. Not to mention people who have no access to
GitHub because of sanctions. It's the ubiquitousness of email that makes it
the best tool for the job even if it's actually terrible for technical
discussions.



If the comparison is between "Mailing List" vs "GitHub Discussions", I 
agree with you. Both of these options are "extremes", though. A possible 
middle-ground option that also was mentioned on GitHub would be a modern 
web forum software.


First things first in the interest of disclosure: I'm employed by 
WoltLab, a company that develops commercial (PHP-based) apps for 
community management ("forum software"). My first PHP RFC 
(SensitiveParameter for 8.2) was developed on company time. After that 
successful RFC I continued participating on the list, mostly in my 
personal time. I'm writing this email in my personal time.


Personally I'm fine with participating on mailing lists. I also 
contribute regularly to another project (HAProxy) that primarily works 
with a mailing list. In fact when contributing external patches, the 
project doesn't use pull requests or some other software assistance. 
Instead patches are mailed around, like it is done with the Linux 
kernel. For the longest time they didn't even have an issue tracker, but 
they are now using GitHub Issues after I was sufficiently


However while my coworkers read the list via externals, I've been 
unsuccessful in encouraging them to also participate directly. Their 
area of expertise is different than mine and they would likely be able 
to also add valuable information that I am not able to add myself. Their 
reasons for non-participation are similar to the reasons already given: 
They don't feel comfortable with the email-based process.


Looping back to the initial paragraph of this email and because several 
participants expressed that one should not just look at the perceived 
advantages of a new solution I used the opportunity to summarize 
existing arguments (and adding my own). For the forum software, I'm 
using my employer's forum software feature set as a specific example, 
depending on the software the feature set might differ. Whether a 
specific point is a plus or minus might be debatable for some of the 
points YMMV :-) Points are listed in no particular order except for the 
prefix. Of course each of the points needs to be weighted with regard to 
importance.


Mailing List:
+ The mailing list already exists and it does the job ("No migration 
effort").

+ Emails can be read offline and replies can reasonably be composed offline.
+ Everyone with an email address is technically able to participate.
+ Users are free to choose an interface / MUA of their choice.
+ Full data Ownership (Message history is stored on PHP's infrastructure).
+ Easy to keep track of unread messages.

~ Search dependent on whether the email is in your local inbox (the 
archives are not easy to search)
~ A tree-based structure is the best option to discuss different 
subthreads, without everything being mixed, however some common MUAs do 
not support threading well, resulting in confusing threading for everyone.
~ The functionality is limited to plaintext emails. This prevents 
annoying stuff like colored emails, but at the same time forces folks to 
send "+1" emails for agreement or to not share their agreement at all.


- No categorization of different topics.
- Little to no moderation functionality.
- Messages cannot be edited.
- Very hard to reply to existing threads when newly subscribing.
- The common problems of emails apply (e.g. bogus rejections by 
overzealous spam filters).

- High barrier of entry (e.g. to set up proper filters).

GitHub Discussions:
+ PHP does not need to provide the infrastructure.
+ "Emoji Reactions" (as a weak signal to gauge agreement without 
creating notifications).
+ Polls (as a stronger signal to gauge opinions without creating 
notifications)

+ Messages can be edited (with edit history).
+ Low barrier of entry (many folks already have a GitHub account)
+ Threads can be grouped in categories.
+ Rich text formatting.
+ GitHub is not likely to go anywhere.

~ Search is not great (at least I often do not find the issues I am 
searching for, using Google does not really work either).

~ Supports sending notifications via email (it's not great, though)
~ Supports replying via email (it's not great, though)
~ Limited support for threading / response trees.
~ Limited moderation functionality.

- Cannot be used offline.
- Referring back to quoted 

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

[Dan Ackroyd]

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 Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Kamil Tekiela]

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 obvious what is a quote and what is not, there is this annoying
rule about bottom posting that makes messages more difficult to read, there
is no code formatting, no editing, no tagging or organizing of message in
any way, and a lot more smaller annoyances. It's the same as SMS or any
other simple chat application. It's just too limited.

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
ubiquitous. And that's what is needed for inclusivity. A lot of senior
developers prefer this kind of communication method so if we asked them to
switch over we could lose them. Not to mention people who have no access to
GitHub because of sanctions. It's the ubiquitousness of email that makes it
the best tool for the job even if it's actually terrible for technical
discussions.

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

[Jakub Zelenka]

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 keep an
> eye on it and do the moderator duties (unfortunately, any public forum
> requires that from time to time).
>
>
I think it's kind of the same as for mailing list and it is quite a rare
event when things need some moderation. But if that happens, I think it
should be actually easier as there are more people with access that can do
the actual moderation.

Cheers

Jakub

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

[Larry Garfield]

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, migrating the entire community to a new 
> platform won't help - we'll still suck at introducing anyone to that 
> platform - and most of what we need is someone who's good with words to 
> update some website copy.

I agree, and it's a common pattern, both here and in the earlier thread about 
deprecations/evolution.

Problems exist.  Both with the mailing list setup we have, and the 
evolution/deprecation process.  It's not reasonable to deny either.

But so often, people lead with "and here's why we should rm -rf and start over" 
or "and here's why you're all terrible" or other extremely not-helpful 
"suggestions."  That poisons the well, and totally saps any energy for working 
on the things that can and should be improved incrementally.

It makes me very sad, because if someone were actually to volunteer to overhaul 
the mailing list signup process and verify that it actually, you know, works 
reliably, there's a good chance they'd be greeted with open arms.  (And a fair 
amount of access skepticism I'm sure, but still, it's no secret that we'd 
benefit from that.)  But that's not what happens.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Stanislav Malyshev]

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 forum 
requires that from time to time).


--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Jakub Zelenka]

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 the reactions. If it goes well, I'll proceed with an RFC
> draft.
>

As can be seen from the reactions, this is very unlikely to be accepted if
proposed.

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
helpful for new people to get reactions without a need to subscribe the
mailing list and it would be also easier for searching, linking previous
ideas, tagging people as well as doing quick polls. It could potentially
bring more people to contribute to PHP. I think this could be also good for
the mailing list as it could potentially reduce a bit of volume especially
for things that are constantly repeating.

Regards

Jakub

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

[Rowan Tommins]

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 name did trigger the fall back, see:https://3v4l.org/mnVWO 
 (Independently of any mechanism introduced to avoid to repeatedly trigger the 
function autoloader.)



I could just about live with that example changing so that the fallback 
was cached, but I definitely don't think an explicit call like 
\foo\strlen('x') should become an implicit alias for \strlen('x'), which 
is apparently the current proposal.


I really like the majority of this proposal, but right now would vote 
against it based on that.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

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 documentation to signpost them better is 
something that can happen right now, whether we move or not.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Arvids Godjuks]

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 one thing clear - email has been and
>> is the most critical communication tool out there and that is not going to
>> change. All those Slacks, Discords, Githubs, Microsoft Teams (why MS sucks
>> at making any type of messaging platform so badly?) in the end do not
>> replace email at all. Your email client cannot go offline just because
>> Amazon US-WEST-1 has died again (yes, it dying is basically a meme now). Or
>> because your provider had a major outage, so now you can't open Github. Or
>> someone misconfigured a BGP route and took down half the internet with it.
>> You can't have a copy of github on your phone, laptop, desktop or any other
>> device stored locally on each one of them giving you resiliency not to lose
>> all that data. What if github gets hacked and someone goes and nukes a
>> bunch of data? Or some DMCA takedown gets claimed against the org and
>> Github is required to comply by law? It does not matter that it might have
>> been bogus or frivolous - unless you have the funds to hire a lawyer and
>> defend yourself in court from which jurisdiction the DMCA came, you are
>> stuffed as a Thanksgiving turkey.
>>
>
> The internet is still the internet and all those issues can still effect
> email. I use gmail and if googles email servers go down email the mail
> server that send the email doesnt have retry setup I wont get that email.
> If my internet goes down I wont get the emails untill its back up. If the
> server PHP used for the maillist server goes down nothing get sent/received.
> The internet and everything connected to it can and will go down. Email
> isn't magically unaffected by that fact.
>
A joke about "people who don't do backups and people who now do backups"
kinda fits.
Those who care - those have their clients configured to fetch and store
their emails locally constantly. I have my phone configured to grab all
emails and have them available offline.  IMAP/POP3 hasn't gone anywhere
too. Having things available offline is something I appreciate more and
more. People have different workflows, and there is a surprising amount of
people I meet who purposefully avoid being constantly online for all kinds
of reasons.
-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

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

[Lynn]

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 many other interesting things to do on the internet.
> But it's not a problem.
>

The rules and etiquette are detached from the mailing list, so it's not
obvious that they even exist.

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

[Stanislav Malyshev]

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 very simple rules and follow them. If that's not for you, that's 
fine - there are many other interesting things to do on the internet. 
But it's not a problem.


why internals mails list is open to the public? So they the public can 
actually collaborate on the open source product they're using?


Yes. And "collaborate" means mutual labor. Part of the labor on the site 
of the new participant is to get familiar with the rules of the 
community. They are not very hard, extensive or complicated. Very little 
effort is required. But yes, non-zero effort - that's the 
"collaboration" part.


"Likes" wasn't my intention. There's no point in wasting countless hours 
on an RFC if it's clear ahead of time that it's not going to pass; and 
right now, even within this thread, it's hard to predict that. And, 


Don't predict - just ask people. If it's any good, you're guaranteed 
plenty of engagement, if anything, frequently too much of it.


choice. While not perfect in any sense, reactions provide a meaningful 
simple way of communicating this relevance with a simple thumbs up/down.


Simple? Yes. Meaningful? Meh.

--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Lydia de Jongh]

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 mailinglist is a little difficult is an advantage
for a list like this and at the other hand should not be a problem for a
developer...;-p

But Github would not be my choice for a forum.

Greetz,
flexJoly



Op wo 12 apr 2023 om 16:16 schreef Rowan Tommins :

> 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 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 off the top of my head:
>
> * Ease of access (is subscribing to e-mail *really* harder than logging
> into Github?)
> * Notification of replies and new threads (I find Github pretty awful at
> controlling e-mails and giving useful activity overviews)
> * Handling of threads and sub-threads (at minimum, a tree view like a
> decent e-mail client; preferably, ability for trusted users to split and
> merge threads)
> * Spam control
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

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

[tag Knife]

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 scale. Probably
> multiple people. Paid for their work, I might add.
>
I don't know, there are already 40+ members in the group, i don't know who
has what permissions though.


> While we can't really say for sure how it would turn out, drawing on my
> experience with online communities of all sorts and seeing what others had
> to deal with on Github, things can get our of control fast.
> GitHub is also not a suitable space to have RFC discussions and all that -
> it's just not the right medium for that. Feedback - yes, gaging a wider
> community for some feedback - sure. And maybe some of the PHP's mailing
> lists can be moved to Github, since there are many.
>


> But internal development lists need to stay where they are. These lists
> are not meant for the general public to drive by and throw in a question or
> two. The noise-to-signal ratio already at times is too high on this list,
> now imagine 10-20-30x the activity that Github will bring. It will become
> unmanageable. You are also required to police your org.
> You also ignore the biggest thing: Github is owned by Microsoft, and
> Microsoft is an American company. It abides by US laws, politics and so on.
> That has consequences and puts PHP project under the same umbrella, which
> the mailing list is not under. Github (Microsoft) can't decide to ban
> someone or ask for someone to be removed as a core developer from the
> mailing list. On Github - they can.
>
> Well there are plenty of mailing list that could be trailed on. PHP-DOCS
for example, could be moved to a discussion board on the php-docs
repository.
https://github.com/php/doc-en

RFCs dont have a repository to belong too.


> 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 one thing clear - email has been and
> is the most critical communication tool out there and that is not going to
> change. All those Slacks, Discords, Githubs, Microsoft Teams (why MS sucks
> at making any type of messaging platform so badly?) in the end do not
> replace email at all. Your email client cannot go offline just because
> Amazon US-WEST-1 has died again (yes, it dying is basically a meme now). Or
> because your provider had a major outage, so now you can't open Github. Or
> someone misconfigured a BGP route and took down half the internet with it.
> You can't have a copy of github on your phone, laptop, desktop or any other
> device stored locally on each one of them giving you resiliency not to lose
> all that data. What if github gets hacked and someone goes and nukes a
> bunch of data? Or some DMCA takedown gets claimed against the org and
> Github is required to comply by law? It does not matter that it might have
> been bogus or frivolous - unless you have the funds to hire a lawyer and
> defend yourself in court from which jurisdiction the DMCA came, you are
> stuffed as a Thanksgiving turkey.
>

The internet is still the internet and all those issues can still effect
email. I use gmail and if googles email servers go down email the mail
server that send the email doesnt have retry setup I wont get that email.
If my internet goes down I wont get the emails untill its back up. If the
server PHP used for the maillist server goes down nothing get sent/received.
The internet and everything connected to it can and will go down. Email
isn't magically unaffected by that fact.

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

[Rowan Tommins]

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 always what you want straight away.




XPosting between issues, PRs and discussions.



URLs do a pretty good job for that. Unless you mean literally posting 
the same text to two places, which sounds like a terrible idea.



You can reply to discussions, PRs, issues via email for those who want 
to keep doing that.



Possibly. Last time I tried, GitHub's notification e-mails were too 
poorly designed to have a good idea of what I was replying to unless I 
clicked through to the web UI.



Contrary to this mailing lists belief, a lot more PHP devs who are 
wanting to contribute to PHP

have a github account already versus access to the mailing list.



As far as I know, you need an e-mail address to sign up to GitHub, so 
logically every single person who has a GitHub account can also sign up 
to this mailing list.


Which makes it, once again, about *the on-boarding process*, not the 
actual list itself.




Discussion categories



Could be useful, maybe. I can't think of many ways to slice this list, 
though; perhaps separating the more technical threads from the more 
organisational ones like this.




General QoC, including code blocks, markdown,



A little bit of formatting might be useful occasionally.

I kind of hate markdown specifically, though. It re-purposes so much 
punctuation, and has so many context-dependent effects, that you have to 
preview every single post.



clean web interface 



One man's "clean" is another man's "eugh, I have to put up with this". A 
federated protocol like e-mail means we all get to choose; a centralised 
forum means we at most get some config switches to twiddle.




choosing what discussions
you want to take part in and not get notifications for disicussions 
you dont care about.



Maybe it's a matter of taste, but I have always found GitHub's 
notification options - both by e-mail and in their web UI - to be 
utterly unusable.


Then again, I don't really think about this list as having 
"notifications" at all - I periodically check the folder containing all 
the mailing list messages for new threads, or unread messages in 
existing threads I'm interested in. It's extremely rare that there are 
so many distinct threads, rather than messages within a single thread, 
that I need anything more than that.


The only difference with a forum would be that I'd have to log into one 
restrictive UI to do that, rather than my choice of mail client. To me, 
that's a net negative.




 Moderation, What would happen if a user decided to spam or flame the 
maillist?
 Once the email is sent you cant delete it from everyone's inbox, 
everyone would get it,

 and how long would the response to ban the user be?


This is a fair point. It does happen occasionally, but so far it's never 
been more than a minor nuisance.


As Arvids says, there's a double-edged sword here too: a lower barrier 
to entry will make this more likely, so volunteers will need to spend 
more time wielding those powers. Or, we'll create explicit barriers to 
access, which will lead us back to ... how we implement and document the 
sign-up process.



I am totally willing to admit people's preferences will vary, but then I 
see comments like this ...



The only downside i can think of is threading, github only does 
level-2 threading.



... and I wonder if others really get that people aren't just defending 
e-mail because we're old and stubborn, we actually like how it works, or 
at least think it has pros as well as cons.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Robert Landers]

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 who proposed it and the idea was universally
> > and unilaterally rejected by all participants.
> >
> >
> 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.

If you want to move the mailing list, you have to discuss it with the
mailing list, otherwise, the mailing list will move but people will
keep emailing each other and then it will be even harder to join a
mailing list without a mailing list.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tag Knife]

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 get a strong opinion out and personally
hate it, But by taking part in this email chain there is an obvious skew
towards keeping it.

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

[Lynn]

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 rejected by all participants.
>
>
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.

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

[Arvids Godjuks]

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 encounter *before* you hit the list.
> > Because if it's the latter, migrating the entire community to a new
> > platform won't help - we'll still suck at introducing anyone to that
> > platform - and most of what we need is someone who's good with words to
> > update some website copy.
> >
>
> I also see a lot of user about the signup process just not working (which
> was also mentioned in this thread),
> users may understand how to signup, but upon doing so, don't get signed up
> at all.
>
> I think a move to github discussions would be better than a mailing list,
> benefits include
>
>1. Choosing discussions to take part in, mailing lists are just an all
>or nothing deal.
>2. XPosting between issues, PRs and discussions.
>3. You can reply to discussions, PRs, issues via email for those who
>want to keep doing that.
>4. Contrary to this mailing lists belief, a lot more PHP devs who are
>wanting to contribute to PHP
>have a github account already versus access to the mailing list.
>5. Discussion categories
>6. General QoC, including code blocks, markdown, clean web interface and
>choosing what discussions
>you want to take part in and not get notifications for disicussions you
>dont care about.
>7. Moderation, What would happen if a user decided to spam or flame the
>maillist?
>Once the email is sent you cant delete it from everyone's inbox,
>everyone would get it,
>and how long would the response to ban the user be?
>
> The only downside i can think of is threading, github only does level-2
> threading.
>

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 scale. Probably
multiple people. Paid for their work, I might add.

While we can't really say for sure how it would turn out, drawing on my
experience with online communities of all sorts and seeing what others had
to deal with on Github, things can get our of control fast.
GitHub is also not a suitable space to have RFC discussions and all that -
it's just not the right medium for that. Feedback - yes, gaging a wider
community for some feedback - sure. And maybe some of the PHP's mailing
lists can be moved to Github, since there are many.

But internal development lists need to stay where they are. These lists are
not meant for the general public to drive by and throw in a question or
two. The noise-to-signal ratio already at times is too high on this list,
now imagine 10-20-30x the activity that Github will bring. It will become
unmanageable. You are also required to police your org.
You also ignore the biggest thing: Github is owned by Microsoft, and
Microsoft is an American company. It abides by US laws, politics and so on.
That has consequences and puts PHP project under the same umbrella, which
the mailing list is not under. Github (Microsoft) can't decide to ban
someone or ask for someone to be removed as a core developer from the
mailing list. On Github - they can.

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 one thing clear - email has been and
is the most critical communication tool out there and that is not going to
change. All those Slacks, Discords, Githubs, Microsoft Teams (why MS sucks
at making any type of messaging platform so badly?) in the end do not
replace email at all. Your email client cannot go offline just because
Amazon US-WEST-1 has died again (yes, it dying is basically a meme now). Or
because your provider had a major outage, so now you can't open Github. Or
someone misconfigured a BGP route and took down half the internet with it.
You can't have a copy of github on your phone, laptop, desktop or any other
device stored locally on each one of them giving you resiliency not to lose
all that data. What if github gets hacked and someone goes and nukes a
bunch of data? Or some DMCA takedown gets claimed against the org and
Github is required to comply by law? It does not matter that it might have
been bogus or frivolous - unless you have the funds to hire a lawyer and
defend yourself in court from which jurisdiction the DMCA came, you are
stuffed as a Thanksgiving turkey.
-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

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

[Thomas Hruska]

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 if the mailing list is actually moving.


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 rejected by all participants.


Communication on GitHub is awkward at best.  GitHub works well as an 
issue tracker for bugs and hosting source code in a central location in 
a way that allows merges to get done without driving everyone up a wall. 
 It's largely terrible at everything else.


As someone who maintains an email server, I completely understand that 
maintaining a functioning email server today has intentionally been made 
prohibitively difficult by Google, Microsoft, and major telecoms in 
their overzealous and extremely misguided attempts to bounce block all 
incoming messaging even from properly configured servers.  And those 
same companies are also to blame for creating broken-by-design email 
clients that no one should be using.  But the IETF shares the majority 
of the blame for _actively_ not fixing numerous issues with email at the 
protocol level.  Running away from email isn't the right solution though.


--
Thomas Hruska
CubicleSoft President

CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.

What software are you looking to build?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tag Knife]

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, migrating the entire community to a new
> platform won't help - we'll still suck at introducing anyone to that
> platform - and most of what we need is someone who's good with words to
> update some website copy.
>

I also see a lot of user about the signup process just not working (which
was also mentioned in this thread),
users may understand how to signup, but upon doing so, don't get signed up
at all.

I think a move to github discussions would be better than a mailing list,
benefits include

   1. Choosing discussions to take part in, mailing lists are just an all
   or nothing deal.
   2. XPosting between issues, PRs and discussions.
   3. You can reply to discussions, PRs, issues via email for those who
   want to keep doing that.
   4. Contrary to this mailing lists belief, a lot more PHP devs who are
   wanting to contribute to PHP
   have a github account already versus access to the mailing list.
   5. Discussion categories
   6. General QoC, including code blocks, markdown, clean web interface and
   choosing what discussions
   you want to take part in and not get notifications for disicussions you
   dont care about.
   7. Moderation, What would happen if a user decided to spam or flame the
   maillist?
   Once the email is sent you cant delete it from everyone's inbox,
   everyone would get it,
   and how long would the response to ban the user be?

The only downside i can think of is threading, github only does level-2
threading.

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

[Derick Rethans]

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 validation for those who are
>> against it.
>>
>>
>> p.s. also excuses like "gmail is making me top-post and that why I can't
>> write to internals" make me sad .. what have we come to / what's in the
>> future ..
>
>Im going to post a reply from reddit which I think encapsulates this
>discussion
>
>Posted by HappyPenguin on reddit
>
>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.

PHP is 27 years old and the language it is written in is 51 years old. Lay it 
off with the ageism. 

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

[Robert Landers]

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 you're interested in doesn't really give a
> > direction at all (unless you're a dev).
> > It mostly boils down "do this, do that, after that figure it out yourself".
>
>
> I'd like to draw attention to a non sequitur between the above, totally
> valid criticism, and the below:
>
>
> > It really shows php's age that you have to join a mailing-list to even get
> > generic user support, let alone participate in development.
>
>
> None of the above has anything to do with it being a mailing list per
> se. You could have just as bad an experience trying to sign up for a web
> forum, or a chat room, or something-something-blockchain-ai-javascript.
>
> But to repeat: the complaints about the sign-up process are totally
> valid. I don't know enough about the system involved to make them
> smoother, but there's no reason signing up for a mailing list can't be
> as simple as enter address, confirm address, done. By all accounts, the
> PHP ones are not.
>
>
> > Look at the "Make WordPress" page compared to php's "Get Involved" page and
> > the overall onboarding experience is so much nicer and improved.
> > People can get a general idea of how teams works, their goals, who's
> > leading who,
> > with helpful guides and direction to get people started.
>
>
> I agree to a point. My first impression of the Wordpress page you
> mention is that it's kind of overwhelming with the number of different
> teams, and it's mostly a directory of Slack channels, I think? (Hurrah,
> another Slack workspace to separately sign into on every device!) A more
> apt comparison is probably to https://www.php.net/mailing-lists.php
>
> What is probably lacking both there and the "Get Involved" page is a
> more direct statement that Internals is the central communication hub
> for the project. The mailing list page describes it as "A medium volume
> list for those who want to help out with the development of PHP" which
> is accurate but entirely unhelpful.
>
>
> 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, migrating the entire community to a new
> platform won't help - we'll still suck at introducing anyone to that
> platform - and most of what we need is someone who's good with words to
> update some website copy.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Heh,

> Hurrah,
> another Slack workspace to separately sign into on every device!

>From working at Automattic for nearly 6 years, I can say that they are
indeed, a very Slack-heavy organization. They used it very well
though, maybe too well ;)

- Rob

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

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 a dev).
It mostly boils down "do this, do that, after that figure it out yourself".



I'd like to draw attention to a non sequitur between the above, totally 
valid criticism, and the below:




It really shows php's age that you have to join a mailing-list to even get
generic user support, let alone participate in development.



None of the above has anything to do with it being a mailing list per 
se. You could have just as bad an experience trying to sign up for a web 
forum, or a chat room, or something-something-blockchain-ai-javascript.


But to repeat: the complaints about the sign-up process are totally 
valid. I don't know enough about the system involved to make them 
smoother, but there's no reason signing up for a mailing list can't be 
as simple as enter address, confirm address, done. By all accounts, the 
PHP ones are not.




Look at the "Make WordPress" page compared to php's "Get Involved" page and
the overall onboarding experience is so much nicer and improved.
People can get a general idea of how teams works, their goals, who's
leading who,
with helpful guides and direction to get people started.



I agree to a point. My first impression of the Wordpress page you 
mention is that it's kind of overwhelming with the number of different 
teams, and it's mostly a directory of Slack channels, I think? (Hurrah, 
another Slack workspace to separately sign into on every device!) A more 
apt comparison is probably to https://www.php.net/mailing-lists.php


What is probably lacking both there and the "Get Involved" page is a 
more direct statement that Internals is the central communication hub 
for the project. The mailing list page describes it as "A medium volume 
list for those who want to help out with the development of PHP" which 
is accurate but entirely unhelpful.



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, migrating the entire community to a new 
platform won't help - we'll still suck at introducing anyone to that 
platform - and most of what we need is someone who's good with words to 
update some website copy.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[tag Knife]

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. also excuses like "gmail is making me top-post and that why I can't
> write to internals" make me sad .. what have we come to / what's in the
> future ..
>
> rr
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


Im going to post a reply from reddit which I think encapsulates this
discussion

Posted by HappyPenguin on reddit

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 a dev).
It mostly boils down "do this, do that, after that figure it out yourself".
It really shows php's age that you have to join a mailing-list to even get
generic user support, let alone participate in development.

Php needs to get with the times, even something as simple as a forum would
be better than mailing lists for discussions.

Reading those responses from people really does not show a welcoming
environment and only puts off people from participating.
The guy may have gone about proposing the change the wrong way, but the
spirit is the same.
Modern users and devs are not going to take the time to join the mailing
list, introduce themselves, and then get possibly 60+ emails a day that
don't pertain to them.

I used to play a star trek RPG that was PBeM, then moved to Yahoo! Groups,
then moved to a software suite called SMS (Sim Management Something)
and last I checked, the group seemed to have moved to an entirely central
wordpress system.
Email lists are outdated and are no longer the right tool for the job in
99.9% of applications.

Look at the "Make WordPress" page compared to php's "Get Involved" page and
the overall onboarding experience is so much nicer and improved.
People can get a general idea of how teams works, their goals, who's
leading who,
with helpful guides and direction to get people started.


Also alot of comments about the internals terrible attitude towards the
author and to general change.

Maybe some reflection on your selfs of how the community perceives these
discussions, after all they are public.

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

[Robert Landers]

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 some GPS stuff

- This list

If this list managed to move over to GitHub, it'd be the first 'big
list' I'm aware of to move to GitHub (does Alex work for GitHub? jk).
Email is one of the first and last forms of 'free, as in free speech'
types of communication on the internet and to give it up for 'likes'
and emojis would be kinda sad.

I enjoy reading my email on the train every morning and evening, and I
hope this list will stay in my email.

Cheers,

Rob Landers
Utrecht Netherlands

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Reinis Rozitis]

> 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/

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. also excuses like "gmail is making me top-post and that why I can't write 
to internals" make me sad .. what have we come to / what's in the future ..

rr

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Claude Pache]

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 ?

> - having to learn the specific, uncommon rules of replying: bottom posting, 
> ...

Quoting relevant portion of previous messages and posting below them, is also a 
convention I’ve observed on other platforms, including github.

> ... word wrapping, ...

Really? I always thought that email clients are able to automatically wrap text 
in incoming messages. At least, I never manually wrap text when writing emails, 
and I have never received any complain that my emails are unreadable, If you 
have an issue with my reply, please complain.

> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.

Maybe *some* popular emailing clients make it difficult... Those that I have 
used so far (which are decently popular) have never had problems.

Now to the point:

> What are your thoughts?

I prefer the mailing list for various reasons already mentioned by others 
(which I won’t repeat).

—Claude

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

[tag Knife]

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 for people, even when
> > using https://externals.io/
>
>
> Pierre has voiced exactly my concerns. The reactions are important exactly
> because they allow to measure the reaction of everyone (incl. daily PHP
> developers like myself), not just the voting group. I'm in no way implying
> that those reactions should actually decide anything; yet, it's a nice
> starting point. In the end, that's kind of the point.
>

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

[Alex Wells]

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 goal here.
>

 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
subscribed to this list who have zero knowledge of C to actually help with
PHP development. However, that doesn't mean that their opinion, concerns or
proposals on some topics is invalid, invaluable or unneeded; at least, I
hope it isn't. Those are people who use PHP daily so it's fair to state
that they're inevitably a part of PHP, even though they might not be
directly helping with the source code. Is this the reason why internals
mails list is open to the public? So they the public can actually
collaborate on the open source product they're using?


> It's not Instagram. Collecting likes is not the goal. If the vote needs
> to be held, we have the RFC process.
>

"Likes" wasn't my intention. There's no point in wasting countless hours on
an RFC if it's clear ahead of time that it's not going to pass; and right
now, even within this thread, it's hard to predict that. And, voting aside,
there's no metric PHP can use to measure how relevant something is to PHP
as a project, regardless of the voting group's choice. While not perfect in
any sense, reactions provide a meaningful simple way of communicating this
relevance with a simple thumbs up/down.

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

[BohwaZ]

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_exceptions

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[BohwaZ]

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 and read
them offline later. Also being able to be offline to write an e-mail is
much better.

Besides, there's already https://externals.io for people who prefer a
web interface.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Claude Pache]

> 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.php.net/rfc/core-autoloading
> 

Hi,

1. The proposed modification of `function_exists()` will break existing code:



as soon as a `bar()` function is defined in global scope, with no obvious hint 
why it suddenly broke. You should either (from my increasing order of 
preference):

* acknowledge it in the “Backward Incompatible Changes” section;

*  default the $autoload extra parameter to `false`;

* 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 name did trigger the fall back, see: 
https://3v4l.org/mnVWO (Independently of any mechanism introduced to avoid to 
repeatedly trigger the function autoloader.)


2. If you add function autoloading, you ought to support constant autoloading 
as well, of course.

—Claude

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

[Stanislav Malyshev]

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 responsibility such as 
participating in PHP development. Encouraging drive-by commentary is not 
something that is a goal here.



  - no formatting, especially code blocks. Sure, they are possible through
HTML, but there's no single common way which all of the emailing clients
will understand - like Markdown


If you have code to contribute, feel free to use pull requests. The list 
is for discussion, and the short blocks appropriate in a discussion 
would do fine with simple copy-paste.



  - no reactions - it's hard to tell whether something is supported or not.


It's not Instagram. Collecting likes is not the goal. If the vote needs 
to be held, we have the RFC process.



Based on those issues and PHP, I propose moving the discussions elsewhere -


I am not really very active anymore on the development side but I would 
say it would make it strictly worse to move the discussion. Especially 
on Github which is not very suitable for such things - it is suitable 
for sharing and managing code.


Also, there already are Slack channels for PHP - and you can create 
another one if you feel like it (or a group on any other social 
platform, if many existing groups are not enough).



What are your thoughts?


Not a good idea.

--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Anton Smirnov]

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()
> function then it will be bound to the global function.

Thanks for the clarification, my scenario falls apart now :D
LGTM. I hope it will be approved.

-- 
Anton

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Lynn]

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
mainly a thing that works for people who have been using it a while and
have everything set up the way it works for them. Maybe I'm wrong, I just
don't consider the nature of mailing lists very accessible nor user
friendly.

In the end it seems to work for the current core contributors, not sure if
it works for future core contributors.

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

[Lynn]

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

[Peter Kokot]

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 works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> 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 the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
> of them are one way (i.e. notifications for something) so they should
> definitely stay that way. Some of them might not even be used anymore.
> However, I want this change to affect all two-way (discussion) mailing
> lists if possible. Also, this does not include moving RFCs themselves to
> GitHub, only the discussion that happens via email.
>
> What are your thoughts?

I also prefer mailing lists in addition to 3rd party GitHub
environment. Professional and large open source projects all use such
mailing lists. These mailing lists include two decades of discussions
which is respectable to continue in such direction.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Pierre Joye]

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 hours and not everyone has tests. Yes, we get it, it's common
> knowledge nowadays that code without test is unmanageable, but if you
> inherited a 15 year old codebase developed by multiple developers in a
> start-up mentality
>


This is wrong in so many levels Agility mindset, startup or not, does not
prevent to do the required cleanups.

These, by the way, are yearly,  worst case.

producing code faster than they could actually plan for and with no tests,
> its going to take some time to clean that up and if I take longer than you
> would, does it mean I matter less as a PHP user?
>
> PHP 8 is pretty great to work with and a lot better than previous
> versions, but there was no opt-in aspect to a lot of PHP breakages. All
> that we're asking here is for a bit more forgiveness to existing code that
> was developed 2 decades ago by a complete different generation and still
> need to run today while we clean it up.
>


Many things that will actually break codes (removal of features f.e.), have
been deprecated for years.

as it has been mentioned, many distributions provide longer support for
older php versions.

If you want the latest php version, you will have to prepare for it,
constantly and changing, cleaning your code constantly.  This is done as
part of the daily feature additions, no need to ask a PO or whoever else,
just add it to your estimates (if you still use them).

However, asking, as nicely as you did, the volunteers here to do it for you
as the language level, won't work.

best,
Pierre

>

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

[Dan Ackroyd]

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.php.net/manual/en/function.runkit7-function-copy and
probably wouldn't be that complicated, or conflict with this RFC.

> It was the latter which brought us `class_alias()` [0]
> and I've used it often in code migrations

Yes, in particular the changing from Twig_Template_Loader to
Twig\Template\Loader migration.

I'll add it to my list at https://phpopendocs.com/rfc_codex It would
seem a good "my first RFC" for someone.

Though, function migration could also be solved in a far more powerful
way. Check my forthcoming reply to Rowan...

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Alex Wells]

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/


Pierre has voiced exactly my concerns. The reactions are important exactly
because they allow to measure the reaction of everyone (incl. daily PHP
developers like myself), not just the voting group. I'm in no way implying
that those reactions should actually decide anything; yet, it's a nice
starting point. In the end, that's kind of the point.

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

[Pierre]

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, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.

It's certainly not a killer feature I'd uproot an entire community for.

Regards,


I sometime wish there was reactions thought. There's ton of message I 
read I'd only wish to say "I agree" without sending a complete email 
polluting the discussion for just this.


A simple up and down count would be great to visually assess how readers 
receipt the message. For long and complex discussions about some 
controversial RFC's this could have some kind of meaning.


It also could allow people to express they like an RFC independently of 
any technical consideration, this could at least give some kind of 
number of people interested in feature X or Y.


I'm not saying this list needs social network features, and I like it 
being as it is, but yes, for RFC, it sure lacks public opinion surveys, 
easy ones I mean, ones that anyone can stumble upon easily and say "I 
want it", "I don't want it" or "I don't care". There are millions of PHP 
developers, and nobody never reaches them to take temperature about how 
useful would be X or Y feature, and that's sad.


I guess some RFC's would probably move faster if the developer that 
tries to push it explicitly knows that hundreds or thousands of people 
are supporting it. It would also give sense to some hard and ingrate 
tasks, and some explicit gratitude, recognition for the work done, it 
could be very positive, and simply nice for the few PHP developers doing it.


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/


Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Arvids Godjuks]

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 works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions
> to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> 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 the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
> of them are one way (i.e. notifications for something) so they should
> definitely stay that way. Some of them might not even be used anymore.
> However, I want this change to affect all two-way (discussion) mailing
> lists if possible. Also, this does not include moving RFCs themselves to
> GitHub, only the discussion that happens via email.
>
> What are your thoughts?
>

One major flaw is: Not everyone has a Github account. And never will.
Because to access the code on it one does not require an account on it.
And GitHub is owned by a corporation, a corporation is beholden to a lot of
laws and restrictions and which means they have to comply with all kinds of
things, including sanctions. Like there are people who write on this list
who are caught up in recent big sanctions and their GitHub accounts were
disabled/deleted because they can't have those. But they can access the
public side of the site and write on this email.
And speaking from experience I know from people I know directly who were
affected by it all - leaving the country did not save them from a lot of
their accounts being suspended. Even those who already lived outside those
countries for a while - because they were a citizen of a specific country
despite having a permit in a European country and living there for a few
years, their account was blocked anyway.

Any big OSS project should have control over its channels and infra to a
degree that if some platform goes away - it does not die overnight. GitHub
is a great place for feedback, and discussions, but not for the formal
process of the PHP Internals. It needs to be independent of any
organisation as much as possible.
-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

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

[Andreas Heigl]

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 :)

But as you mentioned, it's been 7 years. Many things and people have
changed. Particularly, PHP has already "vendor locked in" itself into
GitHub; and there's now a specific solution from them - GitHub discussions,
created specifically to tackle the issues with discussions in GitHub
issues. They're not perfect, but hey, neither are mailing lists.


The vendor lock-in is one of the biggest issues that I see with the 
PHP-project.


Adding the main discussion platform to the locked resources is probably 
not one of the best ideas.


Just my 0.02€

Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg  |
+-+


OpenPGP_signature
Description: OpenPGP digital signature

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

[Rowan Tommins]

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 because it's impractical.
>


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, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.

It's certainly not a killer feature I'd uproot an entire community for.

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Alex Wells]

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 off the top of my head:
>
> * Ease of access (is subscribing to e-mail *really* harder than logging
> into Github?)
> * Notification of replies and new threads (I find Github pretty awful at
> controlling e-mails and giving useful activity overviews)
> * Handling of threads and sub-threads (at minimum, a tree view like a
> decent e-mail client; preferably, ability for trusted users to split and
> merge threads)
> * Spam control
>

Agreed. Notifications might not be the strong side of GitHub, but there's a
way to filter discussion notifications (same as subscribing to the mailing
list) and subscribe/unsubscribe to a specific discussion only. There are
also threads with replies, although there are no sub-threads.

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

[Andreas Heigl]

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 the best UX out there. Here are
some immediate flaws which make the process harder than it should be:
  - having to subscribe to a mailing list to even see the discussions
  - supporting public archives such as externals.io to expose discussions to
the public for those who aren't subscribed and keep historical data
  - having to learn the specific, uncommon rules of replying: bottom
posting, word wrapping, removing footers. It's not to say any of those
rules are complex or hard to follow; it's that they're basically
inapplicable outside of emails, so they're usually not known by newcomers.
Also popular emailing clients don't do any of that automatically, making
each reply tedious.


Those rules are written down in 
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md and 
are in essence a modified version of one of the main rules of the 
internet https://www.rfc-editor.org/rfc/rfc1855


Yes: Most web-based mailinterfaces do not care about those basic rules 
of the internet - why that is is a separate discussion - but there are a 
lot of email-clients around that do care about those.



  - no way of editing a message. Mistakes will always be made, so being able
to quickly fix them would be nice


Email is no quickly written chat. You should read what you wrote, use 
your spell-checker and be 100% sure that that is what you want to 
express. That allows a much more clear and focused discussion as people 
will make sure they have expressed what they wanted with enough time. It 
also reduces the possibility of heated discussions (reduces! not 
eliminates! (-; )

  - no formatting, especially code blocks. Sure, they are possible through
HTML, but there's no single common way which all of the emailing clients
will understand - like Markdown


What do you need formatting for? And most of us can read markdown in 
plaintext emails as well...



  - no reactions - it's hard to tell whether something is supported or not.
This includes both the initiative being discussed and the replies that
follow. Sure, you can usually kind of judge the general narrative based on
the replies, but it's not always clear what's in favor. There are usually
many divergent branches of discussions and it's unknown what's supported
the most.


It's a discussion. A :thumbs-up: is not helpful. And if you want to do 
that: Send an email with exactly that.


The discussion lives from meaningful interaction. Not a thumbsup/down 
echochamber


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 the reactions. If it goes well, I'll proceed with an RFC
draft.


There have been a number of discussions over the years and all came to 
the conclusion that no other medium provided the means that the list 
wanted - at that time. Apart perhaps from NNTP (Did I mention that the 
mailinglists are available via NNTP? or at least should be. If not I 
might have to check the colobus integration...)


There are basically two choices here - a messenger-like platform (i.e.
Slack, Teams) or a developer focused platform like GitHub. While messengers
certainly work, they're more focused on working with teammates rather than
actual discussions. They usually don't have a simple way to navigate
publicly and are poor at separating multiple topics into threads. Some
projects use them for that purpose, but it's usually a worse experience
than what GitHub provides.

GitHub is already used by PHP for both the source code and the issues, so
that is a good candidate, especially since it's a platform designed to
handle cases like this. Also, that should be a much easier transition now
that the source and issues were moved to GitHub.

Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
of them are one way (i.e. notifications for something) so they should
definitely stay that way. Some of them might not even be used anymore.
However, I want this change to affect all two-way (discussion) mailing
lists if possible. Also, this does not include moving RFCs themselves to
GitHub, only the discussion that happens via email.

What are your thoughts?


I assume you already checked the mailinglist-archive and stumbled upon 
https://externals.io/message/87501#87643


I might have missed the new takes that weren't discussed there or that 
might have changed since that discussion.


At least apart from "there are a lot of new people around" and "the new 
people don't want to learn the rules"


Looking forward to your TL;DR

Cheers

Andreas

--
  

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

[Alex Wells]

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: just send a follow up.
>

Well, an edit is certainly more convenient. On GitHub, it's also updated in
real time, so if you just sent it and someone's reading it, they can see
the change immediately, not having to "update" the view.


> * No formatting. What is wrong with plain text, it is how PHP is written ?
>

I'm not sure what you mean here by "is how PHP written". If you're
referring to PHP code, I doubt anyone's actually writing PHP without code
highlighting, style formatting, heredoc etc. It is formatted, although
technically it is still plain text. In that regard, so is markdown.


> * No reactions. If people are interested they will reply.
>

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 because it's impractical.

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

[Derick Rethans]

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

[Rowan Tommins]

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 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 off the top of my head:

* Ease of access (is subscribing to e-mail *really* harder than logging
into Github?)
* Notification of replies and new threads (I find Github pretty awful at
controlling e-mails and giving useful activity overviews)
* Handling of threads and sub-threads (at minimum, a tree view like a
decent e-mail client; preferably, ability for trusted users to split and
merge threads)
* Spam control

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Alex Wells]

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. Particularly, PHP has already "vendor locked in" itself into
GitHub; and there's now a specific solution from them - GitHub discussions,
created specifically to tackle the issues with discussions in GitHub
issues. They're not perfect, but hey, neither are mailing lists.

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

[Christian Schneider]

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 best UX out there.

…

> What are your thoughts?

Also see the recent thread at
https://externals.io/message/119757#119786
where there are some thoughts on the UX points (e.g. editing of messages).

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Alain D D Williams]

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 measure the reactions. If it goes well, I'll proceed with an RFC
> draft.

Please: No.

The nice thing about email is that stuff just hits my mailbox and I deal with
it when I have time. I have my MUA (mutt) always running, I do not want to have
something else to monitor.

Your points:

* having to subscribe. An easy one off task.

* Archives: already done

* Having to learn rules, bottom posting. All communities have rules. As you
say: not hard

* Not way of editing: just send a follow up.

* No formatting. What is wrong with plain text, it is how PHP is written ?

* No reactions. If people are interested they will reply.

I agree that one flaw with email is that it is not good at remembering things,
that is why people do things like writing RFCs.

Note: I mainly lurk on this list, only occasionally making comments.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[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
> calculate a duration or so, not to retrieve the actual time itself.
>


Fair enough, but that makes my first question all the more important: are
there any situations or platforms where generating an hrtime value for
every request would have a performance penalty?

How does that performance (for everyone) compare with a single call to
microtime(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Marco Pivetta]

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
> 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 flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions
> to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> 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 the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
> of them are one way (i.e. notifications for something) so they should
> definitely stay that way. Some of them might not even be used anymore.
> However, I want this change to affect all two-way (discussion) mailing
> lists if possible. Also, this does not include moving RFCs themselves to
> GitHub, only the discussion that happens via email.
>
> What are your thoughts?
>

[PHP-DEV] Moving PHP internals to GitHub

[Alex Wells]

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 flaws which make the process harder than it should be:
 - having to subscribe to a mailing list to even see the discussions
 - supporting public archives such as externals.io to expose discussions to
the public for those who aren't subscribed and keep historical data
 - having to learn the specific, uncommon rules of replying: bottom
posting, word wrapping, removing footers. It's not to say any of those
rules are complex or hard to follow; it's that they're basically
inapplicable outside of emails, so they're usually not known by newcomers.
Also popular emailing clients don't do any of that automatically, making
each reply tedious.
 - no way of editing a message. Mistakes will always be made, so being able
to quickly fix them would be nice
 - no formatting, especially code blocks. Sure, they are possible through
HTML, but there's no single common way which all of the emailing clients
will understand - like Markdown
 - no reactions - it's hard to tell whether something is supported or not.
This includes both the initiative being discussed and the replies that
follow. Sure, you can usually kind of judge the general narrative based on
the replies, but it's not always clear what's in favor. There are usually
many divergent branches of discussions and it's unknown what's supported
the most.

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 the reactions. If it goes well, I'll proceed with an RFC
draft.

There are basically two choices here - a messenger-like platform (i.e.
Slack, Teams) or a developer focused platform like GitHub. While messengers
certainly work, they're more focused on working with teammates rather than
actual discussions. They usually don't have a simple way to navigate
publicly and are poor at separating multiple topics into threads. Some
projects use them for that purpose, but it's usually a worse experience
than what GitHub provides.

GitHub is already used by PHP for both the source code and the issues, so
that is a good candidate, especially since it's a platform designed to
handle cases like this. Also, that should be a much easier transition now
that the source and issues were moved to GitHub.

Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
of them are one way (i.e. notifications for something) so they should
definitely stay that way. Some of them might not even be used anymore.
However, I want this change to affect all two-way (discussion) mailing
lists if possible. Also, this does not include moving RFCs themselves to
GitHub, only the discussion that happens via email.

What are your thoughts?

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

[Dan Ackroyd]

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'll see between PHP 4 and PHP 5 codebases is
> the number of source files - when people had to manually list each file to
> include, they tended to bundle things into larger categories;

Yes.

Or to put it more generally, the ergonomics of using a language (aka
the developer experience) affects how people think and write code. I'm
just going to quote someone from Reddit and my reply, because it
captures the essence of the situation perfectly:

TheBroccoliBobboli wrote in /r/php

>> I'm struggling to see the advantages of this vs working with static
>> class functions, e.g. Helper::function().
>>
>> That's mostly because I can't even remember when I last declared a
>> function outside of a class in any serious project though.

> Danack wrote:
> That the ergonomics of using functions in PHP is currently so bad, that you
> don't use them, is proof enough of why the ergonomics of using them needs
> to be improved, and autoloading is the most obvious improvement.


Nicolas Grekas wrote:
> Then comes my second main question: what does this solve?

Or, to appeal to a higher authority: "There is this one thing that I
noticed recently and that concerns me: PHP devs don’t use functions."
- Nikita Popov 
https://www.npopov.com/2012/08/10/Are-PHP-developers-functophobic.html

Nicolas Grekas wrote:

> It doesn't enable anything that a script generating a list of include
statements couldn't

Exactly the same argument could made against class autoloading.

cheers
Dan
Ack

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Herbert Groot Jebbink]

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 duration or so, not to retrieve the actual time itself.

The reason that I want to migrate from microtime(true) to hrtime(true) is
described in the comment in the PHP manual for hrtime:

"This function is particularly necessary on VMs running on KVM, XEN
(openstack, AWS EC2, etc) when timing execution times.

On these platforms which lack vDSO the common method of using time() or
microtime() can dramatically increase CPU/execution time due to the context
switching from userland to kernel when running the `gettimeofday()` system
call."

This migration is almost done, except in the case when it is used together
with REQUEST_TIME_FLOAT, that's the trigger for this possible RFC. The
extra precision is a bonus, but in my use case not needed. (in fact I
remove it so that old code still works)

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

[Rowan Tommins]

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 reasonable on the face of it.

Are there any performance issues calling hrtime on every request (possibly
platform-specific)?

I note that the existing values are not fetched directly from a time
source, but have some logic for SAPIs to provide a value [1] e.g. from the
Apache request context [2], and then REQUEST_TIME is just
REQUEST_TIME_FLOAT truncated to integer.

Should the same approach happen here? e.g. should all three values be based
on hrtime if the SAPI does not provide a value? Would we even need an extra
value if REQUEST_TIME_FLOAT had enough precision?

[1] https://heap.space/xref/php-src/main/SAPI.c?r=9d5f2f13#1085
[2]
https://heap.space/xref/php-src/sapi/apache2handler/sapi_apache2.c?r=4da0da7f#371

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Rowan Tommins]

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, it
allows lazy-loading, which was an important performance consideration
before opcache; but it also allows mapping of class name to file name. Java
still has to find the source file for each class mentioned, it just has a
more rigid set of rules for where it will look.

One of the big differences you'll see between PHP 4 and PHP 5 codebases is
the number of source files - when people had to manually list each file to
include, they tended to bundle things into larger categories; with
autoloading, they used one file per class. There's probably more
willingness to create new classes in such an arrangement, since they're
easier to find.

I think function autoloading would provide a similar shift in thinking:
rather than one big "functions.php", projects will put smaller batches of
functions together in tighter namespaces. That in turn will make it feel
more natural to create a new file of functions, rather than using a class
full of static methods just to create that grouping.

It doesn't enable anything that a script generating a list of include
statements couldn't, but PHP users aren't used to needing a "build" command
just to discover a new file, so function autoloading feels more natural.

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[Peter Bowyer]

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 first blush, but given that it's closer to an FFI than a proper
> extension API, shortfalls inevitably show up when you try to do anything
> complex.
>

Python's the one I had in mind. Also Node. I've read but not written node
extensions and found them very readable. Even when using Native
Abstractions for Node.js (nan) which adds a macro layer.

With compiled languages I'd think of Nim, Crystal and Swift but have no
practical experience with any of them, only having read the source of a few
extensions and run through the tutorials to write them.


> > And that these days new products come along and provide extensions for
> > other languages but not PHP. Which is a problem I can only work around by
> > writing an extension.
>
> Okay. Why is this a problem?  This is what's right about OSS.  That you
> can take two things and smush 'em together because you need something from
> both.
>

I see this as a problem for PHP users and for PHP adoption.

Lack of PHP support from vendors is a strategic problem for future
ecosystem health. There will be multiple reasons¹ vendors will choose to
support other languages and not PHP, but one certainty is it means funded
startups are not putting their cash towards PHP.

For users of PHP, when we look at using a 3rd party service, I would
imagine most of us don't price in the cost of building, maintaining and
supporting our own extension. The outcome would be to not use the service -
or to change language to one where there isn't this friction. Needing to
write an extension to be able to build your app on top makes the platform
behind before the race is even started.

¹ I am interested to find out what their reasons are. Why don't companies
choose to make PHP extensions? Is it that PHP is inconsequential to them,
the perception that PHP users are too small an audience, difficulty of
creating the extension, or other reasons? They aren't going to answer me as
a random person, but if the PHP Foundation want some market research done
then this is your opportunity.


> > PHP now has FFI which provides an easier way to extend PHP. I have huge
> > hopes for it - but in my experience it doesn't feel finished.
>
> I agree, it's not finished.  But the problem there is also the
> opportunity.  OSS works best when people who have an actual need are the
> ones designing the interfaces and making things better.
>
> I don't pay attention to FFI because I can write PHP extensions on a my
> mobile, while sitting on an island beach and playing board games (true
> story).  I know that's not universally true, but it's why I'm not putting
> the effort in, because I'll end up building the wrong solution by not truly
> understanding the requirements (also a true story, take a look at streams
> sometime).
>
> If it feels like FFI is stalled, it's probably because it's "good enough"
> for the people who got it to this point.  The itch is scratched and the
> need is met.
>
> So when I call the state of FFI an opportunity, I'm not saying "code or
> gtfo" as such is sometime vilified.  I'm saying this is an open source
> project of the purest kind and it really is up to someone to care about a
> thing enough to put in the work to make it better.
>
> And if your reply is, "But I don't know C", then good news! That's another
> opportunity.  PHP is a nice language, but it's not the only one out there.
> C is a mother language, the payoff on learning just keeps coming around.
>

>From the times I have tried (the last one on this list being around PDO and
driver-specific functions) C is not an insurmountable problem, but
understanding the PHP/Zend macros was, even after going through the PHP
Internals book. It looks like the book has been updated since last time
though, which will help.

More recently I have been playing with a DuckDB library using FFI and then
working through the code at
https://github.com/kambo-1st/ipc-duckdb-ffi-extension-workshop /
presentation
https://docs.google.com/presentation/d/1_hGrKsJey9YvFMGrKk34p_hRmfPU4swiaUhCpVygVjo/edit.
That might be manageable to complete.

I won't be stepping up to work on FFI because IMO that requires more
experience than I can bring - in extension writing, and particularly in
using FFI and knowing its strengths and pitfalls inside-out. For keeping
track of what I and others find while using FFI, is this mailing list or a
GitHub issue the best place to record it?

Peter

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

[Herbert Groot Jebbink]

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 microtime(true), for
> this it would be great if REQUEST_TIME_HR would also exist next to
> REQUEST_TIME and REQUEST_TIME_FLOAT
>
> The implementation can be done with adding below 2 lines to
> main/php_variables.c where REQUEST_TIME and REQUEST_TIME_FLOAT are also
> defined.
>
> ZVAL_LONG(, php_hrtime_current());
> php_register_variable_quick("REQUEST_TIME_HR",
> sizeof("REQUEST_TIME_HR")-1, , ht);
>
> With Kind Regards, Herbert
>

pfff, the "forgot to change after a copy/paste" mistake, the variable in
the subject must be $_SERVER['REQUEST_TIME_HR']

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

[Herbert Groot Jebbink]

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 and REQUEST_TIME_FLOAT

The implementation can be done with adding below 2 lines to
main/php_variables.c where REQUEST_TIME and REQUEST_TIME_FLOAT are also
defined.

ZVAL_LONG(, php_hrtime_current());
php_register_variable_quick("REQUEST_TIME_HR", sizeof("REQUEST_TIME_HR")-1,
, ht);

With Kind Regards, Herbert

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

[Nicolas Grekas]

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 functions would become aliases to the new Core
> ones and will continue to work without any migrations needing to be
> performed.
>

Thanks to you and Dan for the RFC.

I have two main questions about this:
1. What's the performance hit?
2. If the perf hit is measurable, is function autoloading worth it? aka
what problem does it address?

About the perf hit, I see that you put a lot of thought into minimizing it
and that's sound. The way I see this feature be spread to userland is via
composer of course. I foresee that composer will add a way for packages to
declare function autoloading. This means that every application that uses
composer will be impacted by the perf overhead eventually (aka the case of
"programs that do not have a function autoloader registered" mentioned in
the RFC won't happen in practice.)

In e.g. https://github.com/php/php-src/pull/6627#issuecomment-773922448,
Dmitry explains that adding inheritance cache to PHP provided a 8% perf
benefit when running a demo app. I would like to see a similar benchmark
with function autoloading enabled. https://github.com/phpbenchmarks/
provides several demo apps so it could be a nice playground for running
this.

Then, depending on the resulting numbers, I anticipate several possible
outcomes:
- if the impact is really low, then all is fine and we can keep things as
is;
- otherwise, I'm also interested in this idea to scope function autoloading
per namespace, so that the engine can filter ahead of calling any userland
autoloaders;
- if the overhead is still significant, could another idea be to load
functions per namespace, where the engine would ensure to call function
autoloaders only once per namespace? Even with the current proposal, I can
easily anticipate that a common practice for package authors could be to
put all functions in one file, and register a function autoloader that
would require that file for any of the functions in it. Loading per
namespace would fit this loading strategy. But before exploring this idea,
let's get some numbers about the performance of the previous approaches.

Then comes my second main question: what does this solve?

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. But because we run PHP mainly in short-lived
request/response loops, loading just the few classes we need to serve a
specific request provides the best performance. In recent versions of PHP,
we may question this practice, since we now have a crazy good opcache. Of
course, I'm not suggesting removing autoloading for classes. But if we do
have that crazy good opcache, what do we need function autoloading for? The
current way for package authors to declare classes is via composer "files
" entry. One could argue in
the past that this adds needless "require" on the hotpath. But if they cost
nothing thanks to recent opcache improvements, we don't need to care, do
we? At least, we need to compare both approaches, because if the main
argument for adding function autoloading is lazy-loading of function
implementations, then it must be faster than eager-loading. This circles
back to my previous question, so we'd really need a thorough perf analysis
IMHO.

Nicolas

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

[Tim Düsterhus]

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 Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tim Düsterhus]

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.php.net/rfc/unserialize_warn_on_trailing_data
PoC Implementation: https://github.com/php/php-src/pull/9630
Discussion Thread: https://externals.io/message/119745

Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Tim Düsterhus]

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's E_DEPRECATED the 
error goes into a separate log file / is sent to a separate error 
collection endpoint and execution continues, whereas any E_NOTICE or 
E_WARNING is converted to an Exception and execution is aborted.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php