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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
