Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124206 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 0A6411A009C for ; Wed, 3 Jul 2024 23:52:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720050835; bh=jltwzoFxRuovI4zLYNk202/g04tE4U/ZyP2ODkYD0BA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=kdNFnrCH2BZw9W+kJT9L3NflUPgvHOzuPgpiaohktS12pQI5jncdJiTsu3JrRZP29 AzrbpGhKBT64pbTtZCdhMZOdIi0BBbg1PnxnRxYgDpaHkJlM47RxRCqSF9v1Wwf47k SEAKX05D70AoIc0JRJJZwqYewwHrkvNVJPbxZ8a3odrXdxd6LyYyYU8bRefZaYlm/+ YuO0vEydbjKz8zndCVID84zVcYKdvL8h4aknVJJhUeucQkgSoArtVSvWZxAIP9DNJ+ gttMgg1IVryrRo4NAAI6gVRb5EBveAGzfXD2EzimAeVXrZltBO6gZHXyRHK2HTPzaS drbrygIy+y4ig== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B4A6F18004A for ; Wed, 3 Jul 2024 23:53:54 +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_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-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (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 ; Wed, 3 Jul 2024 23:53:54 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-651961563d6so628697b3.0 for ; Wed, 03 Jul 2024 16:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1720050751; x=1720655551; 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=/F9tzXTbhAqiVmLBvODsoLr9KCOME7zi+WlYC0aFoiE=; b=vxvpSUei83nV9Q1BrPNuHsfUfD57Yp24nNJyPEyjSNRp4uJz3GM9WzIK4lKw/sJOFp RMDaUSk745dV9mWqS+4fMAFqAIwmPJ22GFiM69obuNJcg1PXrHLAi/2uyJv2ooGkthlq M6ha0FwOLaBI0DM13NKbT8DIDd5b2qmm5bPh2x32VNVWtuqDlns8ouDPxYn0zqK5Nwlm Ov2UI/sKOMcsqt/CM33dAO9nskZbD1bdB6xWXBCXKDcRe8u004D1mL1a5/BgSFl36wvr ZwHpWQRalq3bWdQ+EuLLzhNnTqvXsFvAWazxfib2ifITXfHVsZemxKRmiQcRHkkqa7sl mhdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720050751; x=1720655551; 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=/F9tzXTbhAqiVmLBvODsoLr9KCOME7zi+WlYC0aFoiE=; b=hS840QxtchiKu2x7D86vzvYxgN6aKieypgP65iyZqOASrSgj6u8HNF60E83Pj8OCja ggO0Ew3ZUFUtLnf8pEOvRrjVAdztf8Sv/imsoueKXc2FjmUazcYcyUuA4mA4smVOw4Ew 5wVfDspHzCzc7z2p2fxohlCX3CtsJdVlmwW7vWWDUu4BYsg3Wt1zACXImS44uaOr9wBm UhuzwwBE4P+fgAmF+olFptpTbmXC0T0CZz3SEbQ+9hXWhkq9pnGKl5d2eH7+bK9KMW81 zd1in9RJtgMOhF1Xs9Sibaq5rNxbbbSbRQ1T1BUJkzF0FCSWkNQTCnB8Ow+or+UmkZqx J4KQ== X-Gm-Message-State: AOJu0YxWnOsK3MgieeRvwgwJnH0FF0bsaGrKy39VYTBS+/riAk+V9NxQ O75Z57Upqpn69TlO9rqRBpfGtYoiozEKl3t+Rt7Sn5PjTB9saYVCZX5aWChbtW/7CkyckNOYUa0 Mtb0= X-Google-Smtp-Source: AGHT+IEsniNGB4yTxcjs1xSVPBhdJjghdKBuVwuFPk8OAPoQv1be+jiZvi+5B6WKkwiSc4HIPB1ofQ== X-Received: by 2002:a25:35c5:0:b0:e02:c6fe:aea2 with SMTP id 3f1490d57ef6-e036eafcb89mr13655635276.7.1720050750908; Wed, 03 Jul 2024 16:52:30 -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 3f1490d57ef6-e0361ec1424sm1910953276.43.2024.07.03.16.52.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2024 16:52:29 -0700 (PDT) Message-ID: <86A83E30-00CE-434F-B316-EB9A55F92BDD@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_35EF3A79-473D-4B94-825E-B5E1878759E8" 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] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript) Date: Wed, 3 Jul 2024 19:52:28 -0400 In-Reply-To: <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> Cc: Vincent de Lau , Matthew Weier O'Phinney , Stephen Reay To: PHP internals References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_35EF3A79-473D-4B94-825E-B5E1878759E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 3, 2024, at 7:17 AM, Stephen Reay = wrote: >=20 > Sent from my iPhone >=20 >> On 1 Jul 2024, at 23:33, Mike Schinkel wrote: >>=20 >> Autoloading runs userland code. This means it has the potential = conflict between different packages with different autoloaders >=20 > *Can* run userland code. It doesn't *have to*; FYI spl_autoload = (https://www.php.net/manual/en/function.spl-autoload.php = ) has existed = since php5.1 and works amazingly well.=20 Excellent point! =20 It has been so long that I have seen anyone use that, however, I = actually forgot it exists.=20 > On Jul 3, 2024, at 10:47 AM, Stephen Reay = wrote: > Neither of which is the point I was making - someone claimed that = autoloaders are implicitly userland code. The point is they don't *have* = to be, and there is a perfectly useable one built in to the SPL = extension; if it's "too opinionated" (or the opinions are ones you don't = like), it's hardly the most in-depth of functions, and it already *has* = configurable parts, so adding in more control shouldn't exactly require = a rocket scientist to add, for example, the ability to use the original = case of the class name. Me personally, the opinions that I do not like are the one-symbol-per = file assumption, which is also a key issue I have with PSR-4.=20 #fwiw. > On Jul 3, 2024, at 12:51 PM, Matthew Weier O'Phinney = wrote: > I'm following the packaging threads closely, and the one thing I've = failed to see a solid argument for is _what problems_ the current = approach of using namespaced code doesn't address. I can definitely see = a need for marking things as package private (i.e., not part of the = publicly consumable API), but that also feels like something we could = address in other ways.=20 Understanding that the thread has been a brainstorming thread more than = a proposal thread =E2=80=94 ignoring whether or not it is effective to = brainstorm on this list because of interpersonal list dynamics =E2=80=94 = my two cents in answer to the question of "What problem(s) are we trying = to solve?" 1. Side-by-side symbol loading =E2=80=94 PHP currently makes it = difficult if not impossible to use different versions of the same = library as dependencies of higher-level dependencies. 2. Symbol encapsulation =E2=80=94 Allowing symbols to be hidden from = code that should not use them. 3. Multiple symbols per file =E2=80=94 Finding an approach that would be = able to gain wide adoption for multiple symbols per file=E2=80=94 = without effectively requiring an app to load all source on each page = load =E2=80=94 to better support locality of behavior. See: https://htmx.org/essays/locality-of-behaviour/ 4. Unified loading =E2=80=94 Currently constants, variables, functions, = are the have-nots of the autoloading realm. Providing a manner for = loading them, and a unified manner across all symbols would be even = better. 5. Community buy-in =E2=80=94 While not a goal in and of itself, ideally = there would be a solution that would gain broad support over time so the = approach does not get dismissed by the majority of developers simply for = reasons such as it is not what they are already familiar with. Having = official PHP endorsement would go a long way to address this. -Mike --Apple-Mail=_35EF3A79-473D-4B94-825E-B5E1878759E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jul 3, 2024, at 7:17 AM, Stephen Reay <php-lists@koalephant.com> wrote:

Sent from my iPhone

On 1 Jul 2024, at 23:33, = Mike Schinkel <mike@newclarity.net> wrote:

Autoloading runs userland code. This means it has = the potential conflict between different packages with different = autoloaders

*Can* run userland = code. It doesn't *have to*; FYI  spl_autoload (https://www.php.net/manual/en/function.spl-autoload.php) = has existed since php5.1 and works amazingly = well. 

Excellent point!  

It has been so long that I have seen anyone use = that, however, I actually forgot it exists. 

On Jul 3, 2024, at 10:47 AM, Stephen Reay = <php-lists@koalephant.com> wrote:
Neither of which is the point I was making - = someone claimed that autoloaders are implicitly userland code. The point = is they don't *have* to be, and there is a perfectly useable one built = in to the SPL extension; if it's "too opinionated" (or the opinions are = ones you don't like), it's hardly the most in-depth of functions, and it = already *has* configurable parts, so adding in more control shouldn't = exactly require a rocket scientist to add, for example, the ability to = use the original case of the class = name.

Me = personally, the opinions that I do not like are the one-symbol-per file = assumption, which is also a key issue I have with = PSR-4. 

#fwiw.


On = Jul 3, 2024, at 12:51 PM, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote:
I'm following the packaging = threads closely, and the one thing I've failed to see a solid argument = for is _what problems_ the current approach of using namespaced code = doesn't address. I can definitely see a need for marking things as = package private (i.e., not part of the publicly consumable API), but = that also feels like something we could address in other = ways. 

Understanding that the thread has been a = brainstorming thread more than a proposal thread =E2=80=94 ignoring = whether or not it is effective to brainstorm on this list because of = interpersonal list dynamics =E2=80=94 my two cents in answer to the = question of "What problem(s) are we trying to = solve?"

1. Side-by-side symbol loading =E2=80=94 PHP currently = makes it difficult if not impossible to use different versions of the = same library as dependencies of higher-level dependencies.

2. Symbol = encapsulation =E2=80=94 Allowing symbols to be hidden from code = that should not use them.

3. Multiple symbols per file =E2=80=94 Finding an = approach that would be able to gain wide adoption for multiple symbols = per file=E2=80=94 without effectively requiring an app to load all = source on each page load =E2=80=94 to better support = locality of behavior.

4. Unified = loading =E2=80=94 Currently constants, variables, functions, = are the have-nots of the autoloading realm. Providing a manner for = loading them, and a unified manner across all symbols would be even = better.

5. Community buy-in =E2=80=94 While not a goal in and = of itself, ideally there would be a solution that would gain broad = support over time so the approach does not get dismissed by the majority = of developers simply for reasons such as it is not what they are already = familiar with. Having official PHP endorsement would go a long way to = address this.

-Mike

= --Apple-Mail=_35EF3A79-473D-4B94-825E-B5E1878759E8--