Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121777
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FDC72543-439F-4065-8A4C-F71E30ED72F2"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Thu, 23 Nov 2023 18:55:01 +0700
References: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca>
 <CAPTD5yH9Wk=ADvCRf4K3SVNm+hfyarHr8_4hQAMbt-zDH4zxkA@mail.gmail.com>
 <CAGBsUreqkyoohwL0B7o8WFQLLcekMryDmDRQ1ksoF2FZCt9WOA@mail.gmail.com>
 <34979AED-893F-45DD-B641-A9F4F39B2928@newclarity.net>
 <2D505086-6AD9-4596-A515-85B50F5D12C5@koalephant.com>
 <CALKiJKpKk0vPhE6Q6H=BK4sy5SLsCBG0aET8X5ZiFo_=v+bLyw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CALKiJKpKk0vPhE6Q6H=BK4sy5SLsCBG0aET8X5ZiFo_=v+bLyw@mail.gmail.com>
Message-ID: <709C14FE-3410-4E47-8211-4267C7F44CE5@koalephant.com>
Subject: Re: [PHP-DEV] RFC Proposal - static modifier for classes
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_FDC72543-439F-4065-8A4C-F71E30ED72F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 23 Nov 2023, at 17:21, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On Thu, 23 Nov 2023 at 06:00, Stephen Reay <php-lists@koalephant.com> =
wrote:
>=20
>> I'm disappointed to see yet again that there's this implied notion =
that
>> working with PHP in 2023 means "well surely you must be using =
composer",
>> which leads to "but composer..."  somehow being an accepted argument =
when
>> it comes to missing/incomplete builtin functionality.
>>=20
>=20
>=20
> While I appreciate your point in the general case, in this particular
> thread, the mentions of Composer are really just examples, or can be
> reworded that way:
>=20
> Functions lack autoloading, but in practice this isn't a big problem
> because you can just require_once a file defining them, and as long as
> OpCache is running there's very little performance penalty. If you're =
using
> a package manager or module loading system to integrate multiple
> autoloaders, it's generally easy to add one or more required files as =
part
> of the package / module config - *for example* Composer has a "files" =
array
> in each package's "autoload" config.
>=20
> So the actual assumption is "surely you must be using OpCache", which
> unlike Composer is bundled with PHP.
>=20
> Regards,
> --=20
> Rowan Tommins
> [IMSoP]


(Resending from list-address)

Hi Rowan,

Respectively, I disagree that it's "not a big problem" if your goal is =
to encourage people to use regular functions over classes with static =
methods.

"No autoloading" is clearly a well known barrier to the use of userland =
functions, and "rewriting 'use composer' to 'use require_once'" isn't a =
comparable workaround, as evidenced by:

- https://wiki.php.net/rfc/core-autoloading (from April 2023) paragraph =
2 says:

> The need for such a feature seems very clear as users will create =
=E2=80=9Chelper=E2=80=9D classes with static methods to take advantage =
of autoloading via the class autoloading mechanism.

An email earlier in this thread makes the same point (shiny gold sticker =
if you remember who wrote this):

> The only issue being that we don't have good autoloading support for =
such functions, and that's a whole different problem...



> you can just require_once a file defining them,

To paraphrase a certain secret agent: Do you want people writing =
faux-namespace classes? Because this is how you get people writing =
faux-namespace classes.


> So the actual assumption is


No, the assumption was very clearly written:

> Autoloading is frankly mostly solved by using the `files` block in =
your composer.json's autoload config, and then you don't need to care.

Saying "a package loader" instead of "composer" isn't any better really. =
Autoloading of classes in PHP doesn't require a "package loader" to =
work. PHP ships with a built in class autoloader function, and =
pretending that using 'require_once' everywhere a function is used, is =
just as easy for the developer seem disingenuous to be honest.



Cheers


Stephen=

--Apple-Mail=_FDC72543-439F-4065-8A4C-F71E30ED72F2--