On Tue, 28 Apr 2020 at 12:52, Max Semenik <maxsem.w...@gmail.com> wrote:
> On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins <rowan.coll...@gmail.com> > wrote: > >> One prefix doesn't make a trend. "PhpToken" is a different case - it's a >> token of PHP source code, so the prefix isn't anything to do with avoiding >> name collisions, it's a natural clarification. >> > > There's also SPL, with classes like SplEnum, SplBool, etc. > Those particular examples are part of an extension which has never made it out of "experimental" status, but you're right that there are some like that in core. To be honest, I've never really understood the concept behind SPL being its own extension, and I certainly wouldn't look to its naming conventions as any kind of precedent for future code. Some parts should probably just be considered "part of the language", and their names aren't prefixed: * the various Iterators * Countable interface (why is this in SPL, but ArrayAccess not?) * the various Exceptions * class_implements, class_parents, class_uses * iterator_apply, iterator_count, iterator_to_array * ArrayObject (although its value is debatable) The functions which are prefixed feel like they shouldn't be: * spl_autoload_* (autoloading is a core feature, and using it with __autoload is now deprecated) * spl_object_hash and spl_object_id (why do these need a prefix if the class_* functions don't?) Some of the functionality which is prefixed would be better refined into more complete APIs as their own extensions: * SplFileInfo, SplFileObject, and SplTempFileObject are an incomplete I/O system that doesn't work well with the rest of the language * The data structure classes (SplQueue etc) have various problems, and the new "DS" extension aims to do better That leaves a handful of things which are prefixed but could probably be removed without anyone caring: * spl_classes (no idea what the use case for this would be) * SplObserver and SplSubject (anyone proposing these now would probably be pointed towards PHP-FIG) > > >> To be honest, I'd be perfectly happy with the attributes RFC using the >> class name "Attribute", just as we use "Iterator", "Closure", "Exception", >> etc, etc. At which point the whole thing's a non-issue. >> > > I hope it's not too late to change this before 8.0 is branched? > As far as I know, there's plenty of time. Regards, -- Rowan Tommins [IMSoP]
