Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113168 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87219 invoked from network); 13 Feb 2021 18:11:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Feb 2021 18:11:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2E0AD1804E4 for ; Sat, 13 Feb 2021 09:57:37 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_05,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 13 Feb 2021 09:57:36 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id CD5E85101324 for ; Sat, 13 Feb 2021 17:57:34 +0000 (UTC) To: internals@lists.php.net References: <60256200.1c69fb81.46e68.6437SMTPIN_ADDED_MISSING@mx.google.com> <83fb79ae-13ff-09e7-83ac-3dcf4da4c3ad@processus.org> Message-ID: <26dffe34-135a-68c9-b202-0726f3f78d04@processus.org> Date: Sat, 13 Feb 2021 18:57:34 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] Re: Proposal: namespace the SPL From: pierre-php@processus.org ("Pierre R.") Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit : > You make some good points, Pierre. Here are my main rebuttals: > > 1. "Spl" is already the effective namespace for the SPL because > that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so > on. Its namespace has already been de facto chosen. > > 2. We have two proposals adding new things to the SPL for 8.1, so we > need to decide if they are going into ext/spl as 1. \Spl\Thing, 2. > \SplThing, or 3. \Thing. Keeping the wider vision in mind is a great > principle, but we need to decide on these new additions _now_ despite > not reaching consensus on the wider thing. > > Obviously, I'm hopeful we can agree on using the Spl namespace for > these additions, and any future SPL additions. > > [1]: https://wiki.php.net/rfc/any_all_on_iterable#vote Aside of the fact I don't like "Spl" if a good naming convention comes out with it prefixing all namespaces so be it and I'll be happy. One thing that bother me much in the current proposal is those kind of classes: `Spl\FixedArray -> SplFixedArray`. That's the most important point in my eyes, it should be already named with a deeper namespace, such as: `Spl\[Collection|List]\{FixedArray,Vector,Queue,LinkedList,...}` in order to make space for later other namespaces to take their rightful place, such as: `Spl\Security\{PasswordHash,RandomNumberGenerator,...}` or `Spl\[Io|File|FileSystem]\{FileBuffer,DirectoryIterator}`. Even if it starts with a narrow scope, it *must*, in my opinion, make space for later additions, therefore `Spl\` must be considered as being the "PHP standard library root namespace", in that regard, no classes or functions must live at root, they must be segregated in their own sub-namespace. If we don't do this, we will very much regret it later. Regards, -- Pierre