Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109873
MIME-Version: 1.0
References: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
 <5ea5e72d.1c69fb81.ecd6b.8d05SMTPIN_ADDED_MISSING@mx.google.com>
 <CALKiJKpjwrdhnQT35myRRC-Sx-kFLzNQ6=a7J-_yEyzFm+2XVA@mail.gmail.com>
 <F519C26E-E65E-46E5-9B70-74259310E774@newclarity.net> <29bd50e0-51d5-e8a1-10c4-bf89d42124c3@gmail.com>
 <AF105DAF-59A0-4DE7-B312-EB603A92B22E@newclarity.net> <CALKiJKqnZ3vQ3QrLQH=YfZQsrKcfNHoH5ECb531PQvFauckxhw@mail.gmail.com>
 <CAGgaK7+DK3z8cq+-9EKG7QBxAMP3Whx68_WMfK4hmjLgsW6HGQ@mail.gmail.com>
In-Reply-To: <CAGgaK7+DK3z8cq+-9EKG7QBxAMP3Whx68_WMfK4hmjLgsW6HGQ@mail.gmail.com>
Date: Tue, 28 Apr 2020 13:48:56 +0100
Message-ID: <CALKiJKqH_Oj0oYo+of8Wv+92-8rm+WnxFDsYFGPx=LmJSpoByA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e9aa5705a4594154"
Subject: Re: [PHP-DEV] [RFC] PHP Namespace Policy
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000e9aa5705a4594154
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Apr 2020 at 12:52, Max Semenik <maxsem.wiki@gmail.com> wrote:

> On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins <rowan.collins@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]

--000000000000e9aa5705a4594154--