Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106302
MIME-Version: 1.0
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <CAF+90c8JhV6-aQrsvW8u_xGB-wHmyObEU1Chd64J+x3tkKogQQ@mail.gmail.com>
In-Reply-To: <CAF+90c8JhV6-aQrsvW8u_xGB-wHmyObEU1Chd64J+x3tkKogQQ@mail.gmail.com>
Date: Sat, 27 Jul 2019 10:33:15 +0200
Message-ID: <CADqTB_gCdV-z1aknLpfLLn-RLXHq4t1p0_LvXng2ssacJuD_Bg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fb067f058ea582ff"
Subject: Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
From: rasmus@mindplay.dk (Rasmus Schultz)

--000000000000fb067f058ea582ff
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

...
> Based on the received feedback, I plan to change this proposal from being
> "namespace-scoped" to being "directory-scoped" instead

...


I think that's a better approach.

But please consider doing this without adding another global function that
defines more global (compiler) state?

If it's going to be directory-scoped, using some kind of project root file,
in my opinion, is the more traditional way to declare directory-scoped
boundaries.

For example, if you could just put a "php.json" file in the root of your
namespace folder, this becomes very easy to spot next to your ".gitignore",
"composer.json", "package.json", "tsconfig.json" and any other well-known
project configuration files.

Finding these in the root of any project/library is pretty intuitive -
poking through bootstrapping scripts for a global function call, meh, not
so much.

(This file could be used to declare other repetitive things too - for one,
why is the declare() situation any different from having to repeat a
namespace declaration in every file? This is just another global setting
that could just as well be declared once in a project root file. If this
file were parsable or reflectable by e.g. Composer, this could probably be
used to make the "autoload" section in Composer optional, for one.)

(You could expand upon this feature in the future to add other compiler
options - for instance, toggling global functions, which would allow for
things like correcting inconsistent argument order in the standard
libraries, toggling incompatible language features, toggling improved
defaults for certain functions, a proper strict type-checking mode at some
point in the future, etc...)

--000000000000fb067f058ea582ff--