Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113167 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 83317 invoked from network); 13 Feb 2021 17:16:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Feb 2021 17:16:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9BE961804DC for ; Sat, 13 Feb 2021 09:02:01 -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-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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:02:00 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id s24so2526979iob.6 for ; Sat, 13 Feb 2021 09:02:00 -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=/oTq2+LFvDIq4hC4Kyzar78fyz2Vch4VjRQtklGmZh0=; b=dq0DR4PadYSAayTwleoIUgfwr0WzANuLs7464OnQ3vivLLEJdYpFn+8JeWBoIEvE3w 1LWyGYYh4TSTLm6Jkg0W5jqk4n3JGNA1F71MufB8FbgIqofpwiA0dxkzfYu7gu79xAWD YrKvsJn5VUkr9We1GS77YL3VDCIkQA9X9v4Do= 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=/oTq2+LFvDIq4hC4Kyzar78fyz2Vch4VjRQtklGmZh0=; b=L/pPxppH4Nvwwn2fq6wY1IL+SK82W8ZYsI4AqG9Sw56ASSp/U3QpV1fMB0GQXWme32 vtGDl5pT4T9MT5/sSdD1wNPfFzcnrlqPXnZ7F7qJeHVAW4YXAZ0RUgtWHgcBck2hBCvk fndbWiOLtHZPzooFxcZsc9q/6uRdLj/NPR7Ap6rjFdAsRpUTwGu5emi2R0BaifsPVIB6 o8y62ZdsT4f6Hg0dZKYa8ljqqbdX51BoFsOJOL0lGYM0A+IdfEcBSEeV3aRZopJ26A9/ H0qa3iHuE/zTALTbLsNbvYlEuuiB7HvbPhhT1MFRGSH+HhpLi+A9Ye26vZtfNLbP0WvE +nQQ== X-Gm-Message-State: AOAM532ilTNgJvxwmQzoBpLLwQRglWl/2OUXlkAqCA+mD8uJiSgg9x6k hMx9SSCJSdlIidbKllbnH9ffBqaAT/QwnopEQ7vNZsBld2j3FA== X-Google-Smtp-Source: ABdhPJwpyHHnyDtg6v+PIPecRY+THuypKGz7XZlgZUzxPv+og3yLr8U0K3QqNzGeVgz1z4WN3qxcpAe8l4jBkrlZUT4= X-Received: by 2002:a02:856d:: with SMTP id g100mr7743203jai.10.1613235717077; Sat, 13 Feb 2021 09:01:57 -0800 (PST) MIME-Version: 1.0 References: <60256200.1c69fb81.46e68.6437SMTPIN_ADDED_MISSING@mx.google.com> <83fb79ae-13ff-09e7-83ac-3dcf4da4c3ad@processus.org> In-Reply-To: <83fb79ae-13ff-09e7-83ac-3dcf4da4c3ad@processus.org> Reply-To: Levi Morrison Date: Sat, 13 Feb 2021 10:01:46 -0700 Message-ID: To: Pierre 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 9:25 AM Pierre wrote: > > Le 11/02/2021 =C3=A0 18:48, Chase Peeler a =C3=A9crit : > > I think Spl makes sense (there might be a debate over whether it should= be > > Spl or SPL though). How feasible is it to create generate a deprecation > > notice when the global version is used? I assume the hope is to eventua= lly > > move away from using those, and I don't think that's a horrible BC brea= k > > given that users have enough time to prepare for it. > > Hello, > > For what it worth, I think that Spl is both ugly to read (yes, I like > things not only to be semantic, but elegant as well) and hard to type on > my keyboard (OK subjective point here, both are actually). > > "Spl" does mean somethings, but I'd prefer something more generic such > as "std" or "standard" or "system", or even "stdlib". And it's an > opinion, and we all have one. Even having lowercased namespace names for > PHP standard library wouldn't bother me much: it would make it > consistent in reading (e.g. `use std\array\first` for example, vs > \array_first()` vs `use Spl\Array\first`). OK stupid point here, but > fact is I don't really care, I just try to make a point here: we are > free to invent new things, or get old things from other languages. We > have all the possibilities of the world and beyond offering themselves > to us, the only limit is our imagination. > > I disagree about narrow scope: if we / you don't think about the future, > each narrow iteration will only get more and more inconsistent, each > step will be a flame ware about naming, and no convention or consistency > will emerge. And it will be slow. I will retire before I'll see an Array > class or a `collection` namespace. And I'm not even that old! This will > fatigue people, and kill any kind of good faith or good sense we still > yet have. > > I think that namespacing, even if its implementation starts narrow (this > make sense) should be thought thoroughly with a wider scope, with a > global scheme even more. It should be voted with a complete view of what > it will become, and how that makes stuff consistent across the whole > actual and future SPL. > > I know this has not much chances to happen, because people always > disagree for purely subjective reasons (beauty of names, ease of typing, > semantic meaning of stuff, weird keyboard layout, or just because some > people don't like when it's other people's ideas which get to be chosen > or voted for) anyhow, I think that narrow scope will only gets PHP > standard library farther from its goal than help it. > > This was my 2 cents, > > Best regards, > > -- > > Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > 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