Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125118
Precedence: bulk
MIME-Version: 1.0
References: <21D6F160-5EAE-44FA-907B-E1DAAC1B8D75@rwec.co.uk> <53BD062A-4D7F-4E5D-852E-6D27641213A8@koalephant.com>
In-Reply-To: <53BD062A-4D7F-4E5D-852E-6D27641213A8@koalephant.com>
Date: Fri, 23 Aug 2024 11:19:30 +0100
Message-ID: <CAKxcST9gWHWNyiW09b_uspA2OpeCfz3PeADyYR5KCj18pn4f4Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global,
 then local)
To: Stephen Reay <php-lists@koalephant.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000c28a50620571d9b"
From: dragoonis@gmail.com (Paul Dragoonis)

--0000000000000c28a50620571d9b
Content-Type: text/plain; charset="UTF-8"

On Fri, 23 Aug 2024, 11:02 Stephen Reay, <php-lists@koalephant.com> wrote:

>
>
> > On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>
> wrote:
> >
> > having global as the default mode (even if we provide an option for
> local) is much less disruptive to existing code.
>
> Hi Rowan,
>
> I don't disagree with this summary of the current state, but I think this
> misses an important factor: namespaced functions are currently nowhere near
> as popular as namespaced classes, and a significant part of that is almost
> certainly because we don't have function autoloading, nor any kind of
> visibility controls for functions (eg package private).
>
> Making relative function names do the opposite of relative class names
> sounds like a great way to permanently kill any prospects of encouraging
> developers to use regular namespaced functions in place of static classes
> as "bag of functions", which is what we keep hearing we should use - most
> notably on a recent RFC to embody the concept of a static class.
>
> So we're told "no don't use classes for static functions like that, use
> proper functions".
>
> We already can't autoload them which makes them less appealing, and less
> practical.
>
> In a world where global functions take precedence over local ones because
> some people don't like writing a single \ character, autoloading would be a
> moot point because if you preference global functions you're implicitly
> telling developers they shouldn't write namespaced functions, by making
> them harder and less intuitive to use.
>
>
> Cheers
>
> Stephen



I've taken the time to carefully read Ilija's proposal and all followup
messages.

This is a great proposal, Ilija, it will immediately benefit 95%+ userbase.

It looks to me that the pro's outweigh the con's, as well as Ilija having
done good research here already.

As for next steps, I'm suggesting that Ilija reach out to the core team at
Symfony, Zend, Laravel as well as WordPress, Magento, Drupal teams .. for
their consideration and input, and bring it back here/RFC.

The latter group of project's codebases can be quite "quirky", and quite
creative, in how they use PHP compared to a traditional "framework".

We need to understand how this could negatively impact how their systems
are put together, and we definitely want to, upfront, identify anything we
wouldn't normally think of, that they can spot, since they know their own
codebases better than we do.

We already have the composer analysis, so after we have these
framework/project analysis then we can make a strongly informed decision on
the impact, positively or negatively, this change will make.

Many thanks,
Paul

--0000000000000c28a50620571d9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, 23 Aug 2024, 11:02 Stephen Reay, &lt;<a href=
=3D"mailto:php-lists@koalephant.com" target=3D"_blank" rel=3D"noreferrer">p=
hp-lists@koalephant.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><br>
<br>
&gt; On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:=
imsop.php@rwec.co.uk" rel=3D"noreferrer noreferrer" target=3D"_blank">imsop=
.php@rwec.co.uk</a>&gt; wrote:<br>
&gt; <br>
&gt; having global as the default mode (even if we provide an option for lo=
cal) is much less disruptive to existing code.<br>
<br>
Hi Rowan,<br>
<br>
I don&#39;t disagree with this summary of the current state, but I think th=
is misses an important factor: namespaced functions are currently nowhere n=
ear as popular as namespaced classes, and a significant part of that is alm=
ost certainly because we don&#39;t have function autoloading, nor any kind =
of visibility controls for functions (eg package private).<br>
<br>
Making relative function names do the opposite of relative class names soun=
ds like a great way to permanently kill any prospects of encouraging develo=
pers to use regular namespaced functions in place of static classes as &quo=
t;bag of functions&quot;, which is what we keep hearing we should use - mos=
t notably on a recent RFC to embody the concept of a static class.<br>
<br>
So we&#39;re told &quot;no don&#39;t use classes for static functions like =
that, use proper functions&quot;.<br>
<br>
We already can&#39;t autoload them which makes them less appealing, and les=
s practical. <br>
<br>
In a world where global functions take precedence over local ones because s=
ome people don&#39;t like writing a single \ character, autoloading would b=
e a moot point because if you preference global functions you&#39;re implic=
itly telling developers they shouldn&#39;t write namespaced functions, by m=
aking them harder and less intuitive to use.<br>
<br>
<br>
Cheers<br>
<br>
Stephen</blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">I&#39;ve taken the time to carefully read Il=
ija&#39;s proposal and all followup messages.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">This is a great proposal, Ilija, it will immediately =
benefit 95%+ userbase.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I=
t looks to me that the pro&#39;s outweigh the con&#39;s, as well as Ilija h=
aving done good research here already.=C2=A0</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">As for next steps, I&#39;m suggesting that Ilija reach=
 out to the core team at Symfony, Zend, Laravel as well as WordPress, Magen=
to, Drupal teams .. for their consideration and input, and bring it back he=
re/RFC.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The latter group=
 of project&#39;s codebases can be quite &quot;quirky&quot;, and quite crea=
tive, in how they use PHP compared to a traditional &quot;framework&quot;.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">We need to understand ho=
w this could negatively impact how their systems are put together, and we d=
efinitely want to, upfront, identify anything we wouldn&#39;t normally thin=
k of, that they can spot, since they know their own codebases better than w=
e do.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">We already h=
ave the composer analysis, so after we have these framework/project analysi=
s then we can make a strongly informed decision on the impact, positively o=
r negatively, this change will make.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Many thanks,</div><div dir=3D"auto">Paul</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"> </blockquote></div></div></div>

--0000000000000c28a50620571d9b--