Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125138
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 15:16:19 +0200
To: internals@lists.php.net
Message-ID: <fd1ed582-08d9-4c9d-a5aa-8ee7578c85f5@app.fastmail.com>
In-Reply-To: <64406CFC-D844-46D9-BC08-BCD405D7BB53@cschneid.com>
References: 
 <CAPyj-LCoBY2bPHLmsyONYDbY9aRSraLz5QNskeTiWfpMD0pTSg@mail.gmail.com>
 <c385b525-37f7-446b-aa96-72272ef9e407@app.fastmail.com>
 <CAPyj-LA4kTJTrQZUkn9kNMvWdH6SsFGU5mBO6EcpuUcRpXesgw@mail.gmail.com>
 <d4b18a48-93b0-49c8-821d-f9298e831188@rwec.co.uk>
 <BD6D644E-A90C-49B8-B51A-C9D4C943FDF6@newclarity.net>
 <846D7756-712B-4A7C-9FC6-DB9F858836B8@rwec.co.uk>
 <880ffc27dc9b421407a670c75d5f5ba756870396.camel@ageofdream.com>
 <790534cd-e158-4712-878c-642dfd0e2bad@app.fastmail.com>
 <a0db04a7fa1d9c77b9d2b0110b50a47ef959e98f.camel@ageofdream.com>
 <d26516d7-afaa-4174-81f0-361785908967@app.fastmail.com>
 <d8bf24792d307d07863176772fbf35ec701b6b4b.camel@ageofdream.com>
 <63F3CFAA-0D9A-4323-A1A4-0E3544281ECE@cschneid.com>
 <b44a775b-c264-4d36-b7ff-7075b8d5dbaf@app.fastmail.com>
 <64406CFC-D844-46D9-BC08-BCD405D7BB53@cschneid.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then
 local)
Content-Type: multipart/alternative;
 boundary=4b5b2cfac4df489a82a83b20c61b66af
From: rob@bottled.codes ("Rob Landers")

--4b5b2cfac4df489a82a83b20c61b66af
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Aug 23, 2024, at 14:56, Christian Schneider 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 <lists@ageofdream.com=
>:
> >> > I think we are all trying to achieve the same thing here.
> >>=20
> >> I'm not sure who "we" and what "same thing" here exactly is.
> >=20
> > Nick was replying to me :p, judging by the quoted paragraph.
>=20
> The "all" in his sentence suggested to me that he means more than him =
and you.
> But then again I might have misinterpreted this.
>=20
> > As far as function overloading goes, I recommend checking out a draf=
t 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.
>=20
> Definitely an interesting read, thanks a lot for the work you put into=
 it!
>=20
> > Further, function autoloading is a clearly missing feature that woul=
d be useful in many situations.
>=20
> The "clearly missing" and "many" part is where I disagree. But I was m=
ainly considering current PHP, not future PHP syntax like the Records st=
uff, agreed.
>=20
> > If function autoloading doesn't work out, I will need to take a diff=
erent approach to that syntax (which is fine, but not something I want b=
ecause I chose the syntax for a very good reason).
>=20
> 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 revisi=
t that once the RFC hits the discussion stage.
>=20
> > That being said, I'm not ready to discuss records here, so this is t=
he 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 reco=
rds. There are very many things to work out still, and it is very much w=
ork-in-progress.
>=20
> Also a bit off-topic but I still have to mention it, maybe worth anoth=
er 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 abou=
t future language features when we have this mailing list.

Don't be worried about it too much. Many RFCs start somewhere else first=
 before they end up here. First as an idea, then a draft, then they ask =
friends/coworkers to read them over, etc. By the time it ends up on the =
list, a lot of work has been done (in some cases). Sometimes, they are s=
imple-ish RFCs that need little work and are pretty straightforward, but=
 for more complex ones, there are usually several cycles before it will =
end up on the mailing list. Further, it has come to my attention that an=
 implementation is basically an unwritten requirement, so spending time =
on that is also a delay there. At least, that has been my experience so =
far with that one.

>=20
> I hope this won't mean that questions/suggestions/concerns on this mai=
ling list won't be discredited because of discussions which happened els=
ewhere. I'm sorry if I sound a bit paranoid here but I've been in this s=
ituation before in other (not software related) aspects of my life befor=
e where I was told that something was already decided and people were no=
t willing to go back on certain issues because of that.

The way I look at it, nothing is set in stone until everyone has seen it=
 and had a chance to respond. Yes, there are good reasons that things ar=
e the way they are in that RFC, and during discussion, I expect those re=
asons will come up. I have no idea if those reasons stand up under scrut=
iny, and I won't find out until then. These are all known unknowns.=20

There are some people on the list who believe once it is on the list, it=
 is unchangeable unless you are a voter and act accordingly, such as ign=
oring non-voter concerns. I, personally, feel that shouldn't be how thin=
gs work. It is "our language" (voter or not) and not "Rob's language." I=
 guess we will see how that plays out in the coming months.

>=20
> Regards,
> - Chris
>=20

=E2=80=94 Rob
--4b5b2cfac4df489a82a83b20c61b66af
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Fri, Aug 23, 2024, at 14:56, Christian Schneider wrote=
:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Am 23.08.=
2024 um 12:27 schrieb Rob Landers &lt;<a href=3D"mailto:rob@bottled.code=
s">rob@bottled.codes</a>&gt;:<br></div><div>&gt; On Fri, Aug 23, 2024, a=
t 12:14, Christian Schneider wrote:<br></div><div>&gt;&gt; Am 23.08.2024=
 um 11:34 schrieb Nick Lockheart &lt;<a href=3D"mailto:lists@ageofdream.=
com">lists@ageofdream.com</a>&gt;:<br></div><div>&gt;&gt; &gt; I think w=
e are all trying to achieve the same thing here.<br></div><div>&gt;&gt;&=
nbsp;<br></div><div>&gt;&gt; I'm not sure who "we" and what "same thing"=
 here exactly is.<br></div><div>&gt;&nbsp;<br></div><div>&gt; Nick was r=
eplying to me :p, judging by the quoted paragraph.<br></div><div><br></d=
iv><div>The "all" in his sentence suggested to me that he means more tha=
n him and you.<br></div><div>But then again I might have misinterpreted =
this.<br></div><div><br></div><div>&gt; As far as function overloading g=
oes, I recommend checking out a draft RFC I've been working on a very, v=
ery long time:&nbsp;<a href=3D"https://wiki.php.net/rfc/records">https:/=
/wiki.php.net/rfc/records</a>. In some off-list discussions, it was clea=
r that if I wanted this syntax, I would need to pursue function autoload=
ing.<br></div><div><br></div><div>Definitely an interesting read, thanks=
 a lot for the work you put into it!<br></div><div><br></div><div>&gt; F=
urther, function autoloading is a clearly missing feature that would be =
useful in many situations.<br></div><div><br></div><div>The "clearly mis=
sing" and "many" part is where I disagree. But I was mainly considering =
current PHP, not future PHP syntax like the Records stuff, agreed.<br></=
div><div><br></div><div>&gt; If function autoloading doesn't work out, I=
 will need to take a different approach to that syntax (which is fine, b=
ut not something I want because I chose the syntax for a very good reaso=
n).<br></div><div><br></div><div>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 ge=
t 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 s=
tage.<br></div><div><br></div><div>&gt; That being said, I'm not ready t=
o 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 y=
ou are interested in discussing records. There are very many things to w=
ork out still, and it is very much work-in-progress.<br></div><div><br><=
/div><div>Also a bit off-topic but I still have to mention it, maybe wor=
th another thread:<br></div><div>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 t=
his mailing list.<br></div></blockquote><div><br></div><div>Don't be wor=
ried about it too much. Many RFCs start somewhere else first before they=
 end up here. First as an idea, then a draft, then they ask friends/cowo=
rkers to read them over, etc. By the time it ends up on the list, a lot =
of work has been done (in some cases). Sometimes, they are simple-ish RF=
Cs that need little work and are pretty straightforward, but for more co=
mplex ones, there are usually several cycles before it will end up on th=
e mailing list. Further, it has come to my attention that an implementat=
ion is basically an unwritten requirement, so spending time on that is a=
lso a delay there. At least, that has been my experience so far with tha=
t one.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=
=3D""><div><br></div><div>I hope this won't mean that questions/suggesti=
ons/concerns on this mailing list won't be discredited because of discus=
sions 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 de=
cided and people were not willing to go back on certain issues because o=
f that.<br></div></blockquote><div><br></div><div>The way I look at it, =
nothing is set in stone until everyone has seen it and had a chance to r=
espond. Yes, there are good reasons that things are the way they are in =
that RFC, and during discussion, I expect those reasons will come up. I =
have no idea if those reasons stand up under scrutiny, and I won't find =
out until then. These are all known unknowns. <br></div><div><br></div><=
div>There are some people on the list who believe once it is on the list=
, it is unchangeable unless you are a voter and act accordingly, such as=
 ignoring non-voter concerns. I, personally, feel that shouldn't be how =
things work. It is "our language" (voter or not) and not "Rob's language=
." I guess we will see how that plays out in the coming months.<br></div=
><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br>=
</div><div>Regards,<br></div><div>- Chris<br></div><div><br></div></bloc=
kquote><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></=
body></html>
--4b5b2cfac4df489a82a83b20c61b66af--