Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123914 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 25A391A009C for ; Thu, 27 Jun 2024 03:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719460054; bh=Ad0uQ9YZP8Q8dEOZRXhQaB/ENpLrYSHO2dfkAA+GQQU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=WR+LB0lXcI0iK9eZnItCQDcpI1oyIZIs79Xi/IGqcDm6TEkDo2m/doK2ydlO4iUsN W9qmmtE+OvvFiK/c/mjDMz+i4bEbXlZalhTGzOi7D51rlP7fIu5iKPzSbwgUZbWBoq oujCagtPgzKwZcZJQPvwT+YHKKuT4zLU+ui0TMU1r4OwPlcdchKiKqL5vNaVPq/AV2 6Zmn8dh7DP3EuiUUTu+Q+cE6rlNrD+TeYNMZS3YXUjG0FkntFFX7MUpwKyej0q0OPC N+Gh3f/INIKONxazSOLiQ4Pl5U9KH503mTOa4hVviM4LsGea/uF1cJryIWKCaCUHHj 13/bqOI2YlJ/A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1AEAB18004A for ; Thu, 27 Jun 2024 03:47:34 +0000 (UTC) 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.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) (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 ; Thu, 27 Jun 2024 03:47:33 +0000 (UTC) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-643efaf0786so42366537b3.1 for ; Wed, 26 Jun 2024 20:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1719459975; x=1720064775; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=0XtHi1NDHQv+v0ejUgknTC4PyZMsSEckVwRCsuaNVx4=; b=07vGKUIoGd2AEXhevNUBCxy6d881pLYukAz15xyyQG7ExXbgk4fDPpDMNiitzhjVri j5Y91009KtjoUjmYXOz6O70s6QDKVCFZyUyW+/CyQ6X2YnKgKXPfK79ag8PbWHc2vhnz YT3Znb9nq8fkfbNXYzB2fgJxWMOlSAm6fv8KZIWiBhBwiUmi9SCQUo7Mqdzqxoosd8F2 +EUmfqGKqOlvkCbObj1vHv0APv07Fpu6klOIRj0NHPoJzBUb9Hf4ze/RVoZWqnfE/iO1 xJPr+GBQjXl/QTVfaVcOImShUXspIxJtdVx9nk38+eb2WScZcW/wmYhlkZ/Ga/gpx5sr 19hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719459975; x=1720064775; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0XtHi1NDHQv+v0ejUgknTC4PyZMsSEckVwRCsuaNVx4=; b=n8JbK33RXkPFnce5CyDSNtHXI57A4FsZk25YwnPiq0VvhTx5h0oEorjrAPU+t2hzDz 59GbMNRfDW7SWdc6twf78EPbP9CLm4fPT0Vw2een607eBGBLQgLAvTkViqDDaWdEvJzb YWSvqbH80hgUAPzAh4pDyVFkEfwKTRdlFiCw7Ar2RRfAELvOcrcIY0lPEQlYsUtl3+GX zsthqddfEBUT1ZPpgL5Hk7PXp28ICWPruiHsYY1TADd/UwlHdG1on/kEdjnd6B2/kVZz hf9FvJ4FjnP28BWPZA9SNIlY6uAN5dhICNmZ7B1cyquv2Ok0LjPGrcPxxQgahGH84xWt xsjA== X-Gm-Message-State: AOJu0YzyWH+5jqbwvJxyK0M086U4/XK0Vpj8SVG23AJJGvbfO0Jg+7lW C9wd3jFafG7jUS2sKUD6TNGI1HCKCZfJhWD50j6H6Kozyk5L1VK+tH4srbl9708= X-Google-Smtp-Source: AGHT+IHPcsNzsosJXP1pa1QWz4hry/Z8g1/O9BJ9C07V4ntJm3Ds+NfJiIHpU21745vQ9tqacTRvgg== X-Received: by 2002:a81:92d7:0:b0:61a:b199:9313 with SMTP id 00721157ae682-6433f0e52a0mr103544047b3.16.1719459974918; Wed, 26 Jun 2024 20:46:14 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 00721157ae682-649794195easm1119707b3.65.2024.06.26.20.46.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2024 20:46:14 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_03429779-EC9E-4B25-8326-D256F512A86F" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: [PHP-DEV] [RFC] Static class Date: Wed, 26 Jun 2024 23:46:14 -0400 In-Reply-To: <0b665744-b146-4276-9c55-e71717d974fd@app.fastmail.com> Cc: php internals To: Larry Garfield References: <4596aa73-cfd4-2292-7191-2839a5bab695@php.net> <0b665744-b146-4276-9c55-e71717d974fd@app.fastmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_03429779-EC9E-4B25-8326-D256F512A86F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Larry, > On Jun 26, 2024, at 2:21 PM, Larry Garfield > wrote: > PHP has no concept of packages at present, and thus no concept of = package-level scope. =20 Not entirely true. PHP has static classes, which are stand-ins for packages for as long as = PHP does not inherently support the concept of packages. Arguing "that is abusing static" without offering an alternative is just = Puritanistic logic that ignores pragmatic real world needs. > For marking a function as "package private", the same way you would = for a package-private class today: @internal docblock. It's not ideal = (the ideal would require packages), but it still communicates the = intent, has worked for classes for 15 years at least, and signals "if = you use this class/function/thing and it breaks later, that's on you, = don't come crying to me." Not only is `@internal docblock` not ideal, it sets up those internal = properties to be infected with usage as explained by Hyrum's Law[1]. = Thus providing `@internal docblock` as if it were a viable alternative = to package private is essentially a non-serious argument. > PHP has no concept of packages at present, and thus no concept of = package-level scope. A private static method is private not to a file = or package, but to that class. (The class and file usually correlate in = practice, but there's nothing in the language that mandates that.) I = would love to have a concept of packages that we could use for scope, as = most more recent languages have concluded that is the correct level at = which to enforce visibility, NOT objects/classes. That's an entirely = separate question, however. If you really want people to stop "abusing static" then drive to address = that entirely separate question. Otherwise let others who are more = pragmatic give the language features that they need. As a quick aside, I would argue that PHP should look at its biggest = warts =E2=80=94 which to me include but are not limited to autoloading = and namespaces =E2=80=94 and deprecate them to be replaced with a proper = package system that leverages a symbol compiler instead of autoloading = and that ejects the god-awful choice of using the escape character for = package name separation.=20 But I digress. > To be blunt, 90% of uses of static methods in PHP are a sign the = developer doesn't actually understand OOP and is just writing procedural = code with more steps. The other 10% are either named constructors or = cases that can now be replaced with attributes. Speaking of best practices, there is a growing contingent of software = developers who feel that OOP should not be the future of software[2], = e.g. that it was "a good idea at the time" but now no longer. My point here is that PHP should not let entrenched dogma drive language = design but instead pragmatically evolve as other languages are also = evolving.=20 -Mike [1] https://www.laws-of-software.com/laws/hyrum/ = [2] https://news.ycombinator.com/item?id=3D8676872 = = --Apple-Mail=_03429779-EC9E-4B25-8326-D256F512A86F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Larry,

On Jun 26, 2024, at 2:21 PM, = Larry Garfield <larry@garfieldtech.com> wrote:
PHP has no concept of packages at present, and thus no = concept of package-level scope.  

Not entirely true.

PHP = has static classes, which are stand-ins for packages for as long as PHP = does not inherently support the concept of packages.

Arguing "that is abusing static" without offering an = alternative is just Puritanistic logic that ignores pragmatic real world = needs.

For = marking a function as "package private", the same way you would for a = package-private class today: @internal docblock.  It's not ideal = (the ideal would require packages), but it still communicates the = intent, has worked for classes for 15 years at least, and signals "if = you use this class/function/thing and it breaks later, that's on you, = don't come crying to me."

Not only is `@internal docblock` not ideal, = it sets up those internal properties to be infected with usage as = explained by Hyrum's Law[1].  Thus providing `@internal docblock` = as if it were a viable alternative to package private is essentially a = non-serious argument.

PHP has no concept of packages at present, and thus no = concept of package-level scope.  A private static method is private = not to a file or package, but to that class.  (The class and file = usually correlate in practice, but there's nothing in the language that = mandates that.)  I would love to have a concept of packages that we = could use for scope, as most more recent languages have concluded that = is the correct level at which to enforce visibility, NOT = objects/classes.  That's an entirely separate question, however.

If you really want people to stop "abusing = static" then drive to address that entirely separate question. Otherwise = let others who are more pragmatic give the language features that they = need.

As a quick aside, = I would argue that PHP should look at its biggest warts =E2=80=94 which = to me include but are not limited to autoloading and namespaces =E2=80=94 = and deprecate them to be replaced with a proper package system that = leverages a symbol compiler instead of autoloading and that ejects the = god-awful choice of using the escape character for package name = separation. 

But I digress.

To be blunt, 90% of uses of static methods in = PHP are a sign the developer doesn't actually understand OOP and is just = writing procedural code with more steps.  The other 10% are either = named constructors or cases that can now be replaced with attributes.

Speaking of best practices, = there is a growing contingent of software developers who feel that OOP = should not be the future of software[2], e.g. that it was "a good idea = at the time" but now no longer.

My point here is that PHP should not = let entrenched dogma drive language design but instead pragmatically = evolve as other languages are also evolving. 

-Mike

[1] https://www.laws-of-software.com/laws/hyrum/
[2] https://news.ycombinator.com/item?id=3D8676872
<= /body>= --Apple-Mail=_03429779-EC9E-4B25-8326-D256F512A86F--