Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113169 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94967 invoked from network); 13 Feb 2021 19:59:15 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Feb 2021 19:59:15 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 236991804DC for ; Sat, 13 Feb 2021 11:45:18 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) (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 11:45:17 -0800 (PST) Received: by mail-il1-f172.google.com with SMTP id m20so2287382ilj.13 for ; Sat, 13 Feb 2021 11:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadoghq.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7E2O6ld16Ud0H8Gjgd9O+mCDe4tCQ9sK770SUWSMjuo=; b=MmNL84/nUOn7TYcy3U5IiKvid7kuf9nQJxvLzuaFs1KdSLQPbmHccunJwITaMpgUmh SRe/Qp5NgJAPebCOiugJtJM3OEuyZvIBT+UwcB/WsmmROaf33PH3AjRRVrFofl3uAbrL eIH31l9LFmoVq6n9sFmKxEPys3/hgEJDLCa1k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7E2O6ld16Ud0H8Gjgd9O+mCDe4tCQ9sK770SUWSMjuo=; b=mhGIDqOOwzIFO2eCdLVt69OtXlQihcHPCPnwQs71Yogc/Cyzs+r5zBZgFafUMVfqlR yUYq9fyhHpTUPu4Q9HMpHT4XgO2tD1KKkU5MW5yYiAzbzBGdEoTNxJKkYbaJTixakoa/ eWO1QI5TIHE5gcTj/envxDGQ++SwsF3BmwTi0UMJiqmwFlec5wTDYS5pj66ew1khcR2I IxX43GW8KYn+vmksbeDipw0Kgt+R3wV5IGZrOM4mbMxDQxbx9IpYmjvMRiq8v4M71NvK dHiLBUtanjEvUE7Vu1f3bywR5zCgCeaXa1Nfswkwboug5gbDOYKDC8nRBszi692BW3Tj 2JQw== X-Gm-Message-State: AOAM5313pT6vVFJa6l6KzkyNXVbGmBYNAMZtnwxnxHjqBbl0jhPPAl03 //rYXv7C43ZFRjU0ux/gF95rkOYYHDTcQxKrbHlnsD7T3umrwg== X-Google-Smtp-Source: ABdhPJyhpUUve9ahyXQx2fiETlatenemRF1po1DgOL5pDL+phuo3Qu0iolMLQeIbAAS1oVm/GSxTi2HeNmw2EFsLEJw= X-Received: by 2002:a05:6e02:4ca:: with SMTP id f10mr7207392ils.112.1613245515051; Sat, 13 Feb 2021 11:45:15 -0800 (PST) MIME-Version: 1.0 References: <60256200.1c69fb81.46e68.6437SMTPIN_ADDED_MISSING@mx.google.com> <83fb79ae-13ff-09e7-83ac-3dcf4da4c3ad@processus.org> <26dffe34-135a-68c9-b202-0726f3f78d04@processus.org> In-Reply-To: <26dffe34-135a-68c9-b202-0726f3f78d04@processus.org> Reply-To: Levi Morrison Date: Sat, 13 Feb 2021 12:45:04 -0700 Message-ID: To: "Pierre R." Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Proposal: namespace the SPL From: internals@lists.php.net ("Levi Morrison via internals") On Sat, Feb 13, 2021 at 10:57 AM Pierre R. wrote= : > > Le 13/02/2021 =C3=A0 18:01, Levi Morrison via internals a =C3=A9crit : > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > To be clear, I am arguing that `Spl` be the namespace for future additions to `ext/spl`, and that we alias a few existing types for consistency. Just as `ext/spl` is not the whole PHP standard library (just one small part of it), the `Spl` namespace I am proposing is not the "PHP standard library root namespace" either; it's just the namespace for the bits in `ext/spl`. What you are arguing for was the subject of recent namespacing proposals, which failed to reach consensus. I am intentionally proposing a different solution for a much narrower problem hoping it will stick, so that new additions going into the ext/spl can avoid having this naming discussion every time.