Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125119
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 12:27:21 +0200
To: internals@lists.php.net
Message-ID: <b44a775b-c264-4d36-b7ff-7075b8d5dbaf@app.fastmail.com>
In-Reply-To: <63F3CFAA-0D9A-4323-A1A4-0E3544281ECE@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>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then
 local)
Content-Type: multipart/alternative;
 boundary=9236d0a6527b4cd3867034b5c7dc0a4a
From: rob@bottled.codes ("Rob Landers")

--9236d0a6527b4cd3867034b5c7dc0a4a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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
> I recall the following arguments for changing the current situation ab=
out function look ups:
> - Performance
> - Function autoloading
> - Consistency
>=20
> Did I miss something big?

Nick was replying to me :p, judging by the quoted paragraph.

>=20
> First of all I don't think the performance argument holds enough weigh=
t as I'm very doubtful this impacts performance of a real world applicat=
ion in a significant way. And for people *really* hitting this problem t=
here is a solution already.
> Secondly I am a bit confused about the whole function autoloading disc=
ussion: There is already a good-enough mechanism (putting them as static=
 functions inside a tool class). I just don't consider the hoops we have=
 to jump through to get a more "pure" or fine-grained solution for a spe=
cial problem not worth it. As for the "don't use classes for static func=
tions" I've yet to see a good argument apart from personal preference.
> As far as consistency goes I've yet to encounter someone being confuse=
d about function resolution. But then again I'm not reaching namespaces =
for PHP classes.

As far as function overloading goes, I recommend checking out a draft RF=
C 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 thi=
s syntax, I would need to pursue function autoloading. Further, function=
 autoloading is a clearly missing feature that would be useful in many s=
ituations. 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). That being sai=
d, 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 ver=
y many things to work out still, and it is very much work-in-progress.

>=20
> While modern tooling possibly can adapt source code to the new style e=
fficiently I have to maintain too many installations of PHP projects on =
various hosters to looking forward to that. And the argument that "you c=
an just stay on an old PHP version" is just not a feasible solution eith=
er..
>=20
> Maybe we should take a step back and reevaluate the pros and cons.=20
>=20
> - Chris
>=20

=E2=80=94 Rob
--9236d0a6527b4cd3867034b5c7dc0a4a
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>On Fri, Aug 23,=
 2024, at 12:14, Christian Schneider wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>Am 23.08.2024 um 11:34 schrieb Nick Loc=
kheart &lt;<a href=3D"mailto:lists@ageofdream.com">lists@ageofdream.com<=
/a>&gt;:<br></div><div>&gt; I think we are all trying to achieve the sam=
e thing here.<br></div><div><br></div><div>I'm not sure who "we" and wha=
t "same thing" here exactly is.<br></div><div><br></div><div>I recall th=
e following arguments for changing the current situation about function =
look ups:<br></div><div>- Performance<br></div><div>- Function autoloadi=
ng<br></div><div>- Consistency<br></div><div><br></div><div>Did I miss s=
omething big?<br></div></blockquote><div><br></div><div>Nick was replyin=
g to me :p, judging by the quoted paragraph.</div><div><br></div><blockq=
uote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>First of all=
 I don't think the performance argument holds enough weight as I'm very =
doubtful this impacts performance of a real world application in a signi=
ficant way. And for people *really* hitting this problem there is a solu=
tion already.<br></div><div>Secondly I am a bit confused about the whole=
 function autoloading discussion: There is already a good-enough mechani=
sm (putting them as static functions inside a tool class). I just don't =
consider the hoops we have to jump through to get a more "pure" or fine-=
grained solution for a special problem not worth it. As for the "don't u=
se classes for static functions" I've yet to see a good argument apart f=
rom personal preference.<br></div><div>As far as consistency goes I've y=
et to encounter someone being confused about function resolution. But th=
en again I'm not reaching namespaces for PHP classes.<br></div></blockqu=
ote><div><br></div><div>As far as function overloading goes, I recommend=
 checking out a draft RFC I've been working on a very, very long time:&n=
bsp;<a href=3D"https://wiki.php.net/rfc/records">https://wiki.php.net/rf=
c/records</a>. In some off-list discussions, it was clear that if I want=
ed this syntax, I would need to pursue function autoloading. Further, fu=
nction autoloading is a clearly missing feature that would be useful in =
many situations. If function autoloading doesn't work out, I will need t=
o take a different approach to that syntax (which is fine, but not somet=
hing I want because I chose the syntax for a very good reason). That bei=
ng 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/ph=
p and a GitHub repo if you are interested in discussing records. There a=
re very many things to work out still, and it is very much work-in-progr=
ess.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D=
""><div><br></div><div>While modern tooling possibly can adapt source co=
de to the new style efficiently I have to maintain too many installation=
s of PHP projects on various hosters to looking forward to that. And the=
 argument that "you can just stay on an old PHP version" is just not a f=
easible solution either..<br></div><div><br></div><div>Maybe we should t=
ake a step back and reevaluate the pros and cons.&nbsp;<br></div><div><b=
r></div><div>- Chris<br></div><div><br></div></blockquote><div><br></div=
><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--9236d0a6527b4cd3867034b5c7dc0a4a--