Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110917 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3539 invoked from network); 10 Jul 2020 15:11:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Jul 2020 15:11:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D8133180508 for ; Fri, 10 Jul 2020 07:02:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 ; Fri, 10 Jul 2020 07:02:49 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CC9075C00D9 for ; Fri, 10 Jul 2020 10:02:47 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Fri, 10 Jul 2020 10:02:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=OYOx/f Reb8ZSb6zUskZQQuhR/BEvCGTeLkKW4tXkzb4=; b=Jyl2Svef+Hxf0bTvEFX8Hy V7+F967ij45vOWCe+1T9/vnWOd1Xecx8r/u7i5NfSyFds2zTiEwyjRiKCMoU2BQ4 L1qkDfWlfXvnrV4MDOUxZIrj7KrXChDamO/d7zUp9NwdfWb25G4HFgiJY9hxjoyJ lWdijb57/w9tazxy5cx0oAhFCe5WyVRj177iOgPw8l3lBrZjOHYdPsnfQa3mwU+e x4lva4ZvaVLLiaNQ4JGQ54f7qUWVXKO/xln+wUttofpaFKhBDTjoNDEywFU63Y6a kg5YeHn38WIFzQx64bbE+csO5b7qvBm6F1Shjw+0skjUqU8R/c1qI/1iLpGOY/3A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvddugdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepveehhedvveejledvvefgleevffdtjeekledvkeegheff gfeivdejhffhledtudetnecuffhomhgrihhnpehphhhprdhnvghtnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgv lhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2795914200A2; Fri, 10 Jul 2020 10:02:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-ID: <06e39427-1650-4f06-80fa-d62e52c38755@www.fastmail.com> In-Reply-To: References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com> <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com> Date: Fri, 10 Jul 2020 09:02:26 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics From: larry@garfieldtech.com ("Larry Garfield") On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote: > On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield > wrote: > > > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote: > > > Greetings, Internalians. > > > > > > There has been much talk of the \PHP namespace of late, including one > > > unsuccessful RFC. In the discussion, the pushback broke down into two > > > main camps: > > > > > > * We should never namespace anything ever. > > > * We can namespace things but we need something more concrete than > > > "RFCs can namespace things if they feel like it." > > > > > > I can't do much about the former, but the latter is a solvable problem. > > > To that end, Mark Randall and I have put together a new RFC on the > > > topic, based on a fruitful discussion in Room 11 a few weeks ago to > > > brainstorm what actual guidelines should be for what goes where. > > > > > > https://wiki.php.net/rfc/php_namespace_policy > > > > > > This proposal provides guidance to short circuit future subjective > > > bikeshedding, while still leaving some wiggle room for case-by-case > > > evaluation as needed. That makes it different from prior attempts that > > > did not provide clear guidance for future RFC authors. > > > > > > The specific guidelines offered may or may not appeal to you; those are > > > open to discussion (within reason; we don't want to end up back in "do > > > whatever" land as we know that won't help), but the more important > > > point is that clear guidelines are provided. > > > > > > Also of note, although it uses existing code to demonstrate where > > > classes *would* go under this plan it does not immediately move > > > anything. Those are left for future RFCs that would have to stand or > > > fall on their own merit. It also provides for a very long grace period > > > for any such transitions to minimize disruption. > > > > > > The intent is to bring this proposal to a vote in time for 8.0's freeze > > > one way or another, even though it's unlikely to have any impact on 8.0 > > > itself. It's still a convenient deadline. > > > > > > *dons flame retardant suit* > > > > > > -- > > > Larry Garfield > > > larry@garfieldtech.com > > > > This has reached the 2 week mark, but there's not been much discussion. > > Anyone else want to weigh in? > > > > I want to give it a few more days and possibly revise it to include a Wiki > > page as suggested, but probably will bring it to a vote within the next > > week or so. > > > > Hey Larry, > > As far as I can see, this RFC still doesn't address a primary concern from > previous discussions: Extensions may get moved between PHP and PECL. The > only discussion of this issue seems to be this bullet point: > > > If a feature is removed from PHP-SRC (either to PECL or dropped entirely) > its previously claimed component namespace remains reserved. It MAY be > released by a subsequent RFC, following the standard RFC procedure, at > least one minor version after the feature is removed. That delay is to > minimize backward compatibility impact and allow userland code to migrate > if appropriate. > > To reiterate what the problem is: If the "PHP" namespace is only used by > extensions bundled with php-src, then any time we import an extension from > PECL, that means all the symbols in that extension must get renamed. This > is disruptive to any existing users of the extension, who now have to deal > with different symbol names depending on which PHP version they use. > > Similarly, when extensions get unbundled and moved to PECL, my current > reading of your RFC is that the extension would initially retain the PHP\ > namespace prefix, even though it is no longer vendored by PHP, but the > extension namespace may get reused at a later point in time (which seems > counter-productive to the goal of avoiding naming collisions). > > For me, dealing with PHP <-> PECL moves is an important part of adopting > namespaces in php-src, and I don't think the current proposal addresses > this issue sufficiently. (One way to address it would be to drop the PHP\ > prefix, and use unvendored namespace names for php-src.) > > Regards, > Nikita Hi Nikita. I'm open to ways of handling that. As written right now, yes, a hypothetical \PHP\Foo extension getting moved to PECL should get renamed to \MyCorp\Foo (or whatever). However, it should be reasonably straightforward in most cases to include a user-space shim that does: namespace \PHP\Fop { class Service extends \MyCorp\Foo\Service {} } (Or similar.) And the same for an extension moving into core. I don't really see any alternative that doesn't either: 1) Essentially boil down to that. 2) Allow arbitrary extensions to share a namespace with core code. Eg, one could say that core-packaged extensions and PECL both use \Ext, and \PHP is reserved for the engine proper. However, there's not a great deal in the engine proper, and stuff still sometimes moves from the engine to an extension or vice versa, so it's the same problem just moved elsewhere. I don't expect a namespace vacated by an expelled extension to ever get reused in practice. The RFC established the mechanism by which it could be reclaimed, which I think is important for completeness, but in practice I highly doubt it ever would be without an extremely strong case being made. As I said, I'm open to other ideas for how to handle that move, but I don't really see any ideal ones. --Larry Garfield