Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111070 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62932 invoked from network); 17 Jul 2020 14:04:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Jul 2020 14:04:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1090C1804DB for ; Fri, 17 Jul 2020 05:57:55 -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=-1.2 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,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 out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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, 17 Jul 2020 05:57:54 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A8D205C0165 for ; Fri, 17 Jul 2020 08:57:53 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Fri, 17 Jul 2020 08:57:53 -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=QLD/hG sqPFMm1HTmh7oFA58xIzoMRjU71JRIOkBjqks=; b=EsRr80yj29yrYVqo2DkSiK SI0oeEqp54Hs5h+2kkOhgRC887fsvLW8j1IfxZ3Owl+FE4NHjWyi9ssWL48Z5vD/ 9UN/tWblGtkshxCeHUJpIFFQ+MsMRz7MdnP6Zr8XCF9jN5kZ/HFuXfWNeTT5sPlj /45BPWgQUiMqDJvWxsqVEME+WEWd1GMhuJ9uSGLh0TUHks4wZcnFSF4ZwmYG6i3N O82ZOb44zuilVWHX6bYPLuiMUnKVbhXmGr9b97sz1RTwwkOH6JqZfcieGke2BpZg j16JKfX3M/D08ZZAGGUXYil8Ika5pV+Os4v9G4u9zaXJS04JltjR9uiYleV0cUSw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeigdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepgeelgfekudeivddvteffueejffdthfejieevhefgffek udevkedtvdelvddvffefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3B88D14200A2; Fri, 17 Jul 2020 08:57:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-52-g083df19-fm-idx2020-20200715.003-g083df194 Mime-Version: 1.0 Message-ID: <5a98507d-7fd6-4ff6-9498-ed0c55a8fa7a@www.fastmail.com> In-Reply-To: References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com> <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com> <02b8e816-1f75-48b4-9614-cec236f6bcec@www.fastmail.com> Date: Fri, 17 Jul 2020 07:57:25 -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 17, 2020, at 7:20 AM, Mark Randall wrote: > On 17/07/2020 09:23, Lester Caine wrote: > > So does that also apply to \Ext? Currently the selection of extensions > > is flexible and most distributions allow the easy repackaging of just > > what is available. Creating a 'core' set off extensions under \PHP is > > essentially saying 'you will make these available' while \Ext is a > > second class citizen? Personally I think every package even if relegated > > to PECL deserves to be under \PHP or alternately ONLY the essential core > > engine components go under \PHP and everything else is \Ext > > Things under \PHP will be related to either the engine itself, universal > helpers, or PHP as a language. > > Everything else, including almost all extensions bundled with php-src, > would go under \Ext > > > > Many of the 'exotic' functions such as 'reflection' are not essential > > for writing good code, so a core \PHP which defines an essential working > > set of functions does make sense. What HAS been lost is the development > > of better extensions such as a \Ext\String or \Ext|Array extension that > > is more 'object orientated' while leaving the legacy functions wrapped > > in \PHP ... > > > > Object-orientated styles for strings / arrays provided by the engine > would still go in the root. To provide at little broader perspective: There's several places that code may live: 1. The engine 2. A required bundled extension 3. An optional/disableable bundled extension 4. A non-bundled (PECL) extension 5. User-space Code sometimes transitions from one home to another; extensions get bundled or unbundled, code is moved from engine to extension or back, user-space code is ported to an extension, etc. If there are namespaces used at all to indicate "origin" (which of the above categories it falls into), then at least one of those moves is going to also imply renaming. We could debate which one is least impactful, has the best ROI, has the easiest BC handling, etc., but at least one of those boundaries is going to be bumpier than the others. I personally don't have strong feelings about which boundary we make easier or harder; As long as there is consensus and we have a way to not dump everything in php-src randomly into the global namespace, I'm happy. :-) But any namespace usage is going to imply, well, naming things. (Just be glad we're not also trying to solve caching at the same time here...) If namespaces used by php-src do not indicate origin, then they run the sizeable risk of colliding with user-space code, which is exactly what we're trying to avoid. As far as the depth of the namespace, The three level class name (vendor/component/class.php) is already the nearly universal standard in PHP thanks to PSR-0, PSR-4, and Composer. Really all that's being done here is officially reserving and using PHP (and/or Ext) as the "core vendor," and then following existing conventions. Everything else is already the standard practice across the ecosystem, just said in more formal words with some collaboration processes defined. --Larry Garfield