Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121796
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
In-Reply-To: <CALKiJKrCwTk540i1tzvB3iC=o69DYNf20ZaJ9whyMf96LJd=TQ@mail.gmail.com>
Date: Fri, 24 Nov 2023 13:29:50 +0700
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <51993D16-4C3B-4147-91AE-8F3961760832@koalephant.com>
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>
 <C6AEED2E-197A-4C55-8139-1EB1AB374146@koalephant.com>
 <CALKiJKrJRWyEFkk1-A-4XOS2OJ6rzsj6D55LMcPrOFFSbRidLw@mail.gmail.com>
 <BEBA905E-CF22-4F1E-8CAD-E51B7D480BE0@koalephant.com>
 <CALKiJKrCwTk540i1tzvB3iC=o69DYNf20ZaJ9whyMf96LJd=TQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] RFC Proposal - static modifier for classes
From: php-lists@koalephant.com (Stephen Reay)



> On 24 Nov 2023, at 01:09, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On Thu, 23 Nov 2023 at 14:20, Stephen Reay <php-lists@koalephant.com> =
wrote:
>=20
>>=20
>> Out of the box, with no package manager or module loader or anything, =
you
>> can do as little as call `spl_autoload_register` with no arguments, =
and
>> have working class autoloading.
>>=20
>=20
>=20
> Sure, it's just about possible that you could paste that one line into =
each
> of your PHP files, and they'd all pick up the right classes. But it's =
more
> likely that you have some shared include called "startup.php",
> "boostrap.php", "header.php", etc, which has that line plus a bunch of
> other setup. So, the argument goes that adding a line "require
> 'namespace_foo_functions.php';" to that shared include isn't that big =
a
> problem.
>=20
> (If it happens you are using Composer, the files and config are listed =
in a
> JSON file rather than a PHP one, and Composer generates the shared =
include,
> but the logic's basically the same.)
>=20
> The strongest counter-argument, I think, is that it *scales* badly: =
once
> you have more than a handful of such include files, an autoloader =
solution
> becomes more attractive than listing all the files.
>=20

I think attractive is the wrong word here, but yes in general the issue =
is that it becomes a developer overhead as the number and location of =
files increases, particularly if you want to keep the files organised in =
the filesystem in a similar fashion to classes (i.e. namespaces mapping =
to directory names).

> However, in itself that's not an argument for static classes; it's an
> argument for function autoloading; the argument for static classes =
needs to
> be either:
>=20
> - "admit it, we're never going to get function autoloading";
> - or "I'd want this even if we had function autoloading" (in which =
case the
> discussion of require vs autoloading becomes irrelevant).
>=20

I couldn't agree more - like I said at the start: I have no dog in this =
particular race about static classes, my only concern is the continued =
use of Composer as a flimsy argument about why features aren't required.



Cheers

Stephen=20


> Regards,
> --=20
> Rowan Tommins
> [IMSoP]