Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121749 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6529 invoked from network); 21 Nov 2023 21:56:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Nov 2023 21:56:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 44CAF180034 for ; Tue, 21 Nov 2023 13:56:30 -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=-0.4 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 21 Nov 2023 13:56:29 -0800 (PST) Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3b6cb515917so4078208b6e.1 for ; Tue, 21 Nov 2023 13:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700603785; x=1701208585; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6vlQkcske9cHuUPaF+p1faEpkMSFMFe54bRgrYL6DDY=; b=LBP+tGMJlF1OaI0Q0IBAGE9csEg2N/YQ0cfhCEsOSDHB3mhck51XlDHfHR5yNNfdND U9RMah+XHpi9Gf7++TVZNqz6z7bMmr1KEGPJHWw/D8OAkgF1kZS4h29d+YkcNCM4O4Qg sKouLLpEnDkyCtZieWJ1KhORVdaP/YMZyTNDsYGKfNw6ClLmtsVoD4jFG19qGTnRWrUr dx3+R2pz1a5tOFYtZt4nxWJ1z5ywL/aqEuj8OgNIQfq/1nY7U8cuzDobXWC+NFBzEMHB aaqLQgZKhB47tgey09O8SwMGoiqBW3gTG+IVZbAMtd6dJp/bPFyNEw/P22L4roBeZ/32 2ykw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700603785; x=1701208585; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6vlQkcske9cHuUPaF+p1faEpkMSFMFe54bRgrYL6DDY=; b=BdiY2dVknHRYmtOhw/sVvLtEH5ffV+1dZJ4Pd0/t8nou7ZHgB08cIiKCI9Fo3xM0O3 gD8LYs/f4LlecHYRkB+2C23jAQ/ieEaXmJfBOLTI41PStSWVSdN//+RbidaXtz8NYtza o8LaRzAxR9KQvONX2rQVBDt6L3A/CddZRv73vIyl/GovPTt2WR3pwnvYRa0KrZSMtL9Q KvBHpPMl9XuSQL05nGmTxJ9tismwmnLkiOAwpbjCGnK0JOvnfnQSt7gt1zEno7ADKKu8 263DE/THiHtrm3hX2wN8soMP9tfiJ9nDCogu0bQI84koIOGLfMusi4d4id2lQ/nmC0Fg k/LA== X-Gm-Message-State: AOJu0Yw3lp/iIua9EKlG1GB2ZR5LKr6+EcXvRNYJfgpXq1ZjS0F/rR9U mDrufDItMtUl/Y8AJpFEF0vs+Qs51u4mRdQcLVI= X-Google-Smtp-Source: AGHT+IFX7+tZzGpnhr2/vv0LuRILm6BPfEmb2DQM3/vA+yrWRs3TTWPBPmLQOsRaRBBmIyBrDb2KdGJgW5gitRjVOvI= X-Received: by 2002:a05:6808:14c9:b0:3ad:9540:5475 with SMTP id f9-20020a05680814c900b003ad95405475mr831571oiw.45.1700603785202; Tue, 21 Nov 2023 13:56:25 -0800 (PST) MIME-Version: 1.0 References: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca> In-Reply-To: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca> Date: Tue, 21 Nov 2023 21:56:14 +0000 Message-ID: To: Lanre Waju Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary="00000000000085508f060ab0ac7a" Subject: Re: [PHP-DEV] RFC Proposal - static modifier for classes From: davidgebler@gmail.com (David Gebler) --00000000000085508f060ab0ac7a Content-Type: text/plain; charset="UTF-8" I wouldn't support this, personally. I'm not a voter but I mean just in terms of gauging community feel about the proposal, without unnecessarily repeating what's already been said I just want to register that I'm in agreement with Larry and Kamil's comments. What static classes would achieve goes against the design principles of what a class is and what it's for. Others have noted we already have an adequate namespacing system and via Composer which is a de facto standard in almost all PHP projects today, a means to autoload namespaced functions. But more than that, I think for me - look, I get a lot of language features which are sincerely useful can be argued to be just convenient syntax sugar for things you could technically already do another way. But when I consider features like readonly properties, constructor promotion and readonly classes, I think the functional change goes beyond just syntax sugar. You're getting an enormous saving versus say, trying to make a class with all properties readonly in PHP 7.4. It's not just a little bit of boilerplate trimmed down, it's you now have to write one line of code instead of fifty. So even if I supported the idea of static classes in principle, I'd still be looking at it and thinking really the only convenience, the only syntax sugar here is that you now have to type the word static N-1 fewer times where N is the number of properties and functions in your class. This is not a huge benefit or saving to me. While I wouldn't encourage anyone to design their code this way, for the same reasons Larry has articulated, if you want to design your code this way you already can at basically the same cost of your time and effort and same cost to the PHP engine. I think there'd need to be some persuasively more substantial gain for either the developer or the execution of a script for this proposal to be worth anything. Thanks. -David --00000000000085508f060ab0ac7a--