> On Aug 23, 2024, at 8:56 AM, Christian Schneider <cschn...@cschneid.com> > wrote: > > Am 23.08.2024 um 12:27 schrieb Rob Landers <rob@bottled.codes>: >> On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote: >>> Am 23.08.2024 um 11:34 schrieb Nick Lockheart <li...@ageofdream.com>: >>>> I think we are all trying to achieve the same thing here. >>> >>> I'm not sure who "we" and what "same thing" here exactly is. >> >> Nick was replying to me :p, judging by the quoted paragraph. > > The "all" in his sentence suggested to me that he means more than him and you. > But then again I might have misinterpreted this. > >> As far as function overloading goes, I recommend checking out a draft RFC >> I've been working on a very, very long time: >> https://wiki.php.net/rfc/records. In some off-list discussions, it was clear >> that if I wanted this syntax, I would need to pursue function autoloading. > > Definitely an interesting read, thanks a lot for the work you put into it! > >> Further, function autoloading is a clearly missing feature that would be >> useful in many situations. > > The "clearly missing" and "many" part is where I disagree. But I was mainly > considering current PHP, not future PHP syntax like the Records stuff, agreed. > >> If function autoloading doesn't work out, I will need to take a different >> approach to that syntax (which is fine, but not something I want because I >> chose the syntax for a very good reason). > > I know you do not want to discuss this here as it is off-topic but it kind of > feels the only advantage is to get rid of "new" in the usage of Records. But > I'll leave it at that as to per your request, we can revisit that once the > RFC hits the discussion stage. > >> That being said, I'm not ready to discuss records here, so this is the first >> and last time I'll mention it on the thread. There is a Reddit post in r/php >> and a GitHub repo if you are interested in discussing records. There are >> very many things to work out still, and it is very much work-in-progress. > > Also a bit off-topic but I still have to mention it, maybe worth another > thread: > I understand where you are coming from but at the same time it feels a bit > worrying to me to use another medium (reddit) for a discussion about future > language features when we have this mailing list. > > I hope this won't mean that questions/suggestions/concerns on this mailing > list won't be discredited because of discussions which happened elsewhere. > I'm sorry if I sound a bit paranoid here but I've been in this situation > before in other (not software related) aspects of my life before where I was > told that something was already decided and people were not willing to go > back on certain issues because of that.
FWIW, Rob asked me to review his ideas in email and I pushed him to open up a repo so that discussions could be captured and made public rather than lost to the ethers of private email. The problem with discussing everything on the list from minute one is that the list has a habit of punishing those who bring ideas that are not fully-baked. It is very hard to brainstorm anything on the list without getting shot down by those who expect everything discussed on the list to already be fully fleshed out. Better to get a group of motivated individuals who all want to see a related RFC succeed and get them to work through the issues enough that when (and if) it is brought to the list there will not be obvious negative arguments against it to nip it in the bud when it otherwise could be something worthwhile. Also, whereas only discussion happens on the list, in a repo you can actually start writing a potential implementation and crafting an eventual RFC, so it has the potential to be more productive. Finally, the list is the gatekeeper anyway, so if things are already decided that the list disagrees with, it still won't pass. So, if you feel you are a stakeholder on this idea, I'd suggest celebrating the idea of a repo and joining the discussion there. -Mike P.S. As for using Reddit, I'm not as big of that as its has its own culture that can be just a difficult to incubate ideas as here on this list.
