Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109648 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74825 invoked from network); 15 Apr 2020 13:11:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Apr 2020 13:11:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0D7081804D0 for ; Wed, 15 Apr 2020 04:41:03 -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=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,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-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (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 ; Wed, 15 Apr 2020 04:41:01 -0700 (PDT) Received: by mail-ua1-f53.google.com with SMTP id i22so1185458uak.6 for ; Wed, 15 Apr 2020 04:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CIs+ivRzG9LYx4mapJhmuF2M0mdkPPRpWLQcSPU6FzM=; b=pZ3vr9oQjljLlQOw9AdlfqtuuyK2GNh7aVzyAOxybG7YukvuNYyRuo8Y84qdT0FUR5 JxC3fwk9ZBH+8o/0cu8xBYFbwwyhSEpxy+Xb6mBkMf018aIIghXYSTubvJNipUaWAeTJ JcbTowLz6kVYHIy+c82xqB2xLSwwazmCIGe/BsT6b2hwqmUYQRs2impNtpO/RT7h2CCl 3WCERpX6RK+AzzVeQMcUn7rk+lu93R65pTxNLHHMrTKEioCMGl/ocIX/N7iN3Dd4fvA7 FgOA8n+hZR+u+gzvxZ3n5F/apSd6FP/plnZ1rHl2q1EiGP24yJAtQSivpqvg6uu7Wgya Mfbg== 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; bh=CIs+ivRzG9LYx4mapJhmuF2M0mdkPPRpWLQcSPU6FzM=; b=RxQ4TcdXYo6oI90N5eFNoGhjxJA2F3XhWBfB0YEzyEai1oiCo149t7dCTTMlrGKXs0 CRSGm1vxwSxiRIX3sDtUO/72tefFZTGDEsDiNTEcS9zIVJDb0jPX4kNrRPrRGllnK9s2 4VnC5gL88Y2rnwxB4b9zec5E5GpgGz4t/QzYhQ+ybt8jEL0Zwgf5hFeRGHGDMUbzUFkL dI/b6ypsgvBG2vLO/T5ymRBQi9BOCVSTSC4DHDy8/fkMjpM/k82jzNfXHUlnFJV9HHgO MCOmG42r+6yfIv1ixBGARB7gcO222SYjNo+qe2CT0+x51EkcLES7QmfBHXiLtep92X5g JEnQ== X-Gm-Message-State: AGi0Pub7IQkDSVBJrQuSrPkWrqgzTDkF1xSfY9oIWtE9nx9WXpVnHmay iWyBeW7NS89zymPQSNmBtyLouZzB7kprv/3NA70JMA== X-Google-Smtp-Source: APiQypLIQl4+zjL0Ylqwb/ymXlbmSYPkFuYOs9BWa/fKclasJ49h3Y3o7HefyXRvLC5HusvozhQ1HmTTWwewHmX7XjA= X-Received: by 2002:ab0:26cd:: with SMTP id b13mr3973416uap.101.1586950860489; Wed, 15 Apr 2020 04:41:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 15 Apr 2020 12:40:49 +0100 Message-ID: To: Mark Randall Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] PHP Namespace Policy From: Danack@basereality.com (Dan Ackroyd) On Wed, 15 Apr 2020 at 12:21, Mark Randall wrote: > > Rather than seek to demand everything be moved into namespaces, I have > instead written this RFC as something that would form a policy > guideline for future development of the engine and those extensions > which are directly managed by internals. > https://wiki.php.net/rfc/php_namespace_policy Hi Mark, Everything is a trade-off. Putting core functions under a namespace makes those core functions harder to use, as people would need to 'use' those functions to make them available in their current namespace. Even assuming the reasons in the RFC are correct, the tradeoff between them and 'making core functions harder to use' does not seem a great tradeoff to make. Another benefit of having core PHP symbols in the root namespace is that it means we can avoid having the discussion of what the namespace naming rules should be. Again, the tradeoff of having to spend time on that discussion of how to name things vs a possible small benefit of having new symbols under a namespace, seems a bad tradeoff. Is there anything you want to add to the RFC to change that view? > This RFC would establish the protocol for a registry, upon > which internals and core extension authors can, as part of their RFC, ... This is a direct suggestion of how to slow down productivity from the CIA "Simple sabotage field manual"*: (11) General interference with Organizations and Production (b) Managers and supervisors (13) Multiply the procedures and clearances involved in issuing instructions, pay checks, and so on. See that three people have to approve everything where one would do. Even if you think namespaces might help a little, I don't think introducing a new procedure for RFCs would be worth that cost. cheers Dan Ack * "Simple sabotage field manual" - https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf Note, the CIA still had the name OSS when published.