Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110746 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 54132 invoked from network); 27 Jun 2020 17:19:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Jun 2020 17:19:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1935F1804C7 for ; Sat, 27 Jun 2020 09:07:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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, 27 Jun 2020 09:07:43 -0700 (PDT) Received: by mail-qk1-f170.google.com with SMTP id k18so11625528qke.4 for ; Sat, 27 Jun 2020 09:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jqFxbVW26JqkLY1OCOu5tMAtKzmuwxF5nU6pGJ9xrto=; b=GGsly03qp6FalgCMtgnWFl8jCl8wuLbPMlYYun+kYyLNbkLGkzHvLv9xbQbjXPvk1T +3rmNbxXMsLm6LSmwxWw312sRitflLQ2axdBkKig5k5QW2zycVK3pgie1zBudbtTUjmg pFaEvWjwd3v7dB9Oa1HEnDXqlVHB+ZOhipfewlv44KkhY/Fynabs6KjB8bo/cuWTV2bK jzZyGyHMvJ4dheC40PYsFAmBZ8t8JcNhpBW8SCah+dvrfHv2sKqQjtUYCyarm9BabFmQ BTUyQXuKtzhPRlFSWodhNBZ7YiK9uLNc3kL/VsvMKSSaRwBcvpQ3YfxBqqXnbfCeCvwu r3Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jqFxbVW26JqkLY1OCOu5tMAtKzmuwxF5nU6pGJ9xrto=; b=eZWQvPoaG2zL5jvAlR6a8ZO8ViTF+e+aapqeahZ8RvPtdCgy+HFEX0w4g/sTfVQZLR GYSep4PcD48UNy/kkX9I33GJ3S/i8tASzTPGzLaPSODex7utoT4MhvXeV5VN4ZbldCwX KOcdnEk6rpTRdKsKte1qcJ8GcsDHGcjKwUFT7CHO4/de8bkyI3zu9aZcOsba7ozXZh6y Kk6Qb8PTO4/4Cwo6rQsCVWvlkwDEldUgGoMrABmAc8+8QMZV5fTWYeBLjkPwqkTvl6Eh ru8gKI5EP3eBL/XUhZ88F9TXgnyaGnAq+yW7oNTvak5/9jENALQDdqCmFBEpTm9fJXYZ BJ5g== X-Gm-Message-State: AOAM530ZSRgt82woWzdwyLRpWZ2KX7CJ+h82RgBaFB9/QgBFOEu8ScRF ZbkpIO8ZVVoRqoUUijswWx4+zQ== X-Google-Smtp-Source: ABdhPJynkhtri7M7ft4qUewoA80hKcM2IoDAFJsrnmWFjmj1UIHTeXEfDotb47PIvQbDf+x4+jHQkQ== X-Received: by 2002:a37:4a85:: with SMTP id x127mr7602635qka.159.1593274063007; Sat, 27 Jun 2020 09:07:43 -0700 (PDT) Received: from ?IPv6:2601:c0:c680:5cc0:a187:8274:c6e6:9ce? ([2601:c0:c680:5cc0:a187:8274:c6e6:9ce]) by smtp.gmail.com with ESMTPSA id c7sm12448221qta.95.2020.06.27.09.07.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2020 09:07:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) In-Reply-To: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com> Date: Sat, 27 Jun 2020 12:07:40 -0400 Cc: php internals Content-Transfer-Encoding: quoted-printable Message-ID: <41ACEF6F-D853-4EB1-BFAE-3CCFFA4583D1@newclarity.net> References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com> To: Larry Garfield X-Mailer: Apple Mail (2.3445.104.14) Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics From: mike@newclarity.net (Mike Schinkel) > On Jun 23, 2020, at 8:30 PM, Larry Garfield = wrote: >=20 > Greetings, Internalians. >=20 > There has been much talk of the \PHP namespace of late, including one = unsuccessful RFC. In the discussion, the pushback broke down into two = main camps: >=20 > * We should never namespace anything ever. > * We can namespace things but we need something more concrete than = "RFCs can namespace things if they feel like it." >=20 > I can't do much about the former, but the latter is a solvable = problem. To that end, Mark Randall and I have put together a new RFC on = the topic, based on a fruitful discussion in Room 11 a few weeks ago to = brainstorm what actual guidelines should be for what goes where. >=20 > https://wiki.php.net/rfc/php_namespace_policy >=20 > This proposal provides guidance to short circuit future subjective = bikeshedding, while still leaving some wiggle room for case-by-case = evaluation as needed. That makes it different from prior attempts that = did not provide clear guidance for future RFC authors. >=20 > The specific guidelines offered may or may not appeal to you; those = are open to discussion (within reason; we don't want to end up back in = "do whatever" land as we know that won't help), but the more important = point is that clear guidelines are provided. >=20 > Also of note, although it uses existing code to demonstrate where = classes *would* go under this plan it does not immediately move = anything. Those are left for future RFCs that would have to stand or = fall on their own merit. It also provides for a very long grace period = for any such transitions to minimize disruption. >=20 > The intent is to bring this proposal to a vote in time for 8.0's = freeze one way or another, even though it's unlikely to have any impact = on 8.0 itself. It's still a convenient deadline. >=20 > *dons flame retardant suit* >=20 This looks really good Larry. Very well thought-out.=20 If I could vote it would be a definitive "Yes." -Mike