Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127530 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 lists.php.net (Postfix) with ESMTPS id D7AD01A00BC for ; Mon, 2 Jun 2025 13:28:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1748870763; bh=JitGsKgTZaO7/exatc/EO9boATeymCS1EtkFKP9Yc3g=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Quq9JIIV30zZqGSyAxFMuQWHheiWk/D+0LZZ8JJmgbPJiHcv7T8HhwX1mciJYNyHg x7x8HGLWB/kIn9uL2WkqvF+CLwc9M9GqXgNKpVyCdlF3fIfJRyuDnp4QV0s+61UeZr WTLYMVIe5IDTOBxNg7atpy0gI0J7FsYs7qwxfxHufT8n/22sNbDIyykrydKlhVN1JU tJ7ytaH8BcWtFgdv5gLJCidKLP7W6v1sCsqecRnV3eyCvK6d49Wi7khzScKcoL7VQP SUkgtRtP53stVE50QWLo0wV4f7a/gkbwfw+WmkoZ/buYKGmoKsXA8OqTn0lzo2y88G a4xssaADf8u/A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BBE1B18006C for ; Mon, 2 Jun 2025 13:26:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 ; Mon, 2 Jun 2025 13:26:02 +0000 (UTC) Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 68C5311401BD for ; Mon, 2 Jun 2025 09:28:06 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-10.internal (MEProxy); Mon, 02 Jun 2025 09:28:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to; s=fm1; t=1748870886; x=1748957286; bh=CQ9+QYLS9kszH3M+M8DZ2 woK5iQwXRfJNW9qpKzF2M0=; b=ppRXju6raRA7+6LhM7uV5u8WPFJYWKkG1pVc6 sXJw6lN5i6n/dV+3p++eYyXk1AU/RxAckBd6miqj6/09kWpR/FsD4mmhgTWRk5Fd wCRa/alc+WaTyLcMzMMq8PvT7NCFX1+dAnKWQmY52zPmqO89ieWx3fRis03xALKB LrV5Tj/4J62H4POIbd0vE8AEm6Mav6dgSJOOnVTygO3LXMNe1mu/I6FAcuuBixep +taeDyy548iPCwY/MXoWNoZZifDkZVNrRqU/Bo4hFI+Yjn83jAv3+uXxwosKJZ0c r4eLsP1qRfJCfslooJAZtnNuLvWo3R4AnZiaFN1XCa2K8CHNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1748870886; x=1748957286; bh=C Q9+QYLS9kszH3M+M8DZ2woK5iQwXRfJNW9qpKzF2M0=; b=dUxnMM/6rJUKko0H1 hfppdwadpMr99UdTLTTu87cyveUrd/szMwTEZqa8nfpwv1KLAxxdH+g2k63rx534 G/q1lAuUEezN7ogGHEhuuFAQcRhjHsxf0TlBMLLRmfotQpaScNqHXdm5XE4W8Plr 9fj7f1U6jItzYAayu3ugTR9N5xfaNOMVaMiWzqPI/eHjSsPVOdd85pHfm0SRgMuC TmIyviMf+1izRmIwI8wzkUPcZ3LVNrzWUpAZRAUhJpN7w7ncD3NMC4MH+Yo+oWj0 bT8yL70LM0WGXtg+V95HAH00UATDR07omN48Z7I1rDAz322b5XhI6t0UNC6DDP3v Pm2qQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefjeejleculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefoggffhffvkfgj fhfutgfgsehtjeertdertddtnecuhfhrohhmpedfnfgrrhhrhicuifgrrhhfihgvlhgufd cuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomheqnecuggftrfgrthhtvghr nhepudegvdelgfeugeehfeejteffudevleethfefgeejffffleegtddtveekgeekudfgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhr hiesghgrrhhfihgvlhguthgvtghhrdgtohhmpdhnsggprhgtphhtthhopedupdhmohguvg epshhmthhpohhuthdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhp rdhnvght X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id E9355700061; Mon, 2 Jun 2025 09:28:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: Te4ea9ce7af33d8fb Date: Mon, 02 Jun 2025 08:27:45 -0500 To: "php internals" Message-ID: In-Reply-To: <2c5c241c-bd05-4200-b6ee-e94c8ab0db1b@rwec.co.uk> References: <354cb888-97c4-4f8c-a0da-359d1e63c0f9@rwec.co.uk> <10D95B6E-094B-4EAE-A18A-AF6B795CB352@rwec.co.uk> <2adbff61-5e11-4d39-ab5c-d7950a4550a6@app.fastmail.com> <79E7FA26-2F5A-470C-B1DF-12CC46A08FE5@rwec.co.uk> <1c6dcd84-9016-48e1-971f-de7749cbdce8@rwec.co.uk> <44F59416-3922-4AF4-881A-C64F2C4E9345@rwec.co.uk> <7F11844A-A98C-4843-BC94-815FBCD2B73F@garsi.de> <7840468C-F60C-4A44-AE40-16F9007EF428@rwec.co.uk> <160E9B1D-9AF6-479B-A628-A73C618D7C1B@garsi.de> <2c5c241c-bd05-4200-b6ee-e94c8ab0db1b@rwec.co.uk> Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: larry@garfieldtech.com ("Larry Garfield") On Sun, Jun 1, 2025, at 5:01 PM, Rowan Tommins [IMSoP] wrote: > On 01/06/2025 17:05, Larry Garfield wrote: >> I think there's a key assumption here still that is at the root of much of the disagreement in this thread. >> >> Given that code from multiple files is clustered together into a "thing" >> and Given we can use that "thing" to define a boundary for: >> * name resolution (what Michael is after); >> * visibility (what I am after); >> * more efficient optimizations (what Arnaud showed is possible); >> * various other things >> Then the key question is: Who defines that boundary? >> >> Is it the code*author* that defines that boundary? Or is it the code*consumer*? >> >> Similarly, is it the code author or consumer that has to Do Work(tm) in order to leverage the desired capability? Or both? > > > My take on this is that both need to exist as *separate* features. > > The author should define the boundary for things like visibility and > optimisation. It should be possible to take an existing Composer > package, add some metadata to it in some way, and have the engine make > some useful assumptions. The consumer of that package should not need to > care about the difference, except in edge cases like trying to define > additional classes with the same prefix as a third-party package. > > On the other hand, the consumer should define the boundary for isolating > name resolution. It should be possible to take any folder of PHP files, > with no metadata about package management, and load it in a context > where duplicate class names are allowed. The author of the package > shouldn't need to make any changes, except in edge cases like highly > dynamic code which needs additional hints to work correctly when sandboxed. Were we to do that, then the consumer container-loading needs to take any potential module-definition into account. Eg, if one class from a module is pulled into a container, all of them must be. Though I'm still not clear how transitive dependencies get handled either way. Crell/Serde depends on Crell/AttributeUtils, which depends on Crell/fp. If someone wants to containerize, say, the ObjectImporter from Serde, will that necessarily mean containerizing Serde, AttributeUtils, and fp? If so, how will it know to include all of those, but not include Crell/Config (which uses Serde)? And while I know we keep trying to get away from talking about Composer and autoloading, for any of this to work, Composer would need to be modified to allow downloading multiple versions of a package at the same time and keeping them separate on disk. I do not know what that could look like. --Larry Garfield