Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121777 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37415 invoked from network); 23 Nov 2023 11:55:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Nov 2023 11:55:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A071118002F for ; Thu, 23 Nov 2023 03:55:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DMARC_MISSING, HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 23 Nov 2023 03:55:22 -0800 (PST) Received: from smtpclient.apple (unknown [49.48.245.183]) by mail1.25mail.st (Postfix) with ESMTPSA id E4E026064A for ; Thu, 23 Nov 2023 11:55:14 +0000 (UTC) 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> <34979AED-893F-45DD-B641-A9F4F39B2928@newclarity.net> <2D505086-6AD9-4596-A515-85B50F5D12C5@koalephant.com> To: PHP internals In-Reply-To: Message-ID: <709C14FE-3410-4E47-8211-4267C7F44CE5@koalephant.com> X-Mailer: Apple Mail (2.3774.200.91.1.1) 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 = wrote: >=20 > On Thu, 23 Nov 2023 at 06:00, Stephen Reay = 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--