Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121768 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11140 invoked from network); 23 Nov 2023 06:00:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Nov 2023 06:00:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6FA5B18003F for ; Wed, 22 Nov 2023 22:00:25 -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, 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 ; Wed, 22 Nov 2023 22:00:24 -0800 (PST) Received: from smtpclient.apple (unknown [49.48.245.183]) by mail1.25mail.st (Postfix) with ESMTPSA id BC5CA6063A for ; Thu, 23 Nov 2023 06:00:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Date: Thu, 23 Nov 2023 12:59:59 +0700 References: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca> <34979AED-893F-45DD-B641-A9F4F39B2928@newclarity.net> To: PHP internals In-Reply-To: <34979AED-893F-45DD-B641-A9F4F39B2928@newclarity.net> Message-ID: <2D505086-6AD9-4596-A515-85B50F5D12C5@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) > On 21 Nov 2023, at 06:48, Mike Schinkel wrote: >=20 > Wow.=20 >=20 Hi, (This is not a direct reply to Mike, his just seems to be less shouty = than other recent emails) I'm not *particularly* bothered by the results of this specific RFC = either way - a *similar enough* result is already possible by grouping = static methods in an abstract class, but 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. Despite the way some treat it, this isn't the composer internals list, = nor is composer a required or even bundled part of PHP. =20 Does that mean you shouldn't use composer? No, if it works for your = project, that's great. Does that mean gaps in the php language/standard library should be = automatically ignored/glossed over because composer may provide a = work-around? Also, no. PHP has for a very long time stood out amongst other web-focused = languages for having a very rich standard library out of the box = ('batteries included', I think the cool kids would say now). Let's please not take PHP in the direction of "modern JavaScript" where = language deficiencies mean that an entire alphabet of constantly = changing third-party tooling is required to do anything but the simplest = tasks. Cheers Stephen