Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH0Uv3FnYf_c7in4_6AmDO5pUZHsgU0m5scjU5oRz2kTAJ=+bw@mail.gmail.com>
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <c31d2b02-220f-dda3-c232-564f94877dc1@gmail.com> <CAF+90c82gVkwMK11B__HuNoSUz3eHx1VmG5PoNu6yJuTAUO3fw@mail.gmail.com>
 <CAH0Uv3FnYf_c7in4_6AmDO5pUZHsgU0m5scjU5oRz2kTAJ=+bw@mail.gmail.com>
Date: Wed, 13 Dec 2017 05:04:23 +0100
Message-ID: <CABdc3WpomNLz+vX_m0B0wQ3uCiMiw8xw4Ea_sGD-PTDGfV-PbA@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c1e9930e1495d056030dcae"
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c1e9930e1495d056030dcae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2017-12-13 1:16 GMT+01:00 Andreas Hennings <andreas@dqxtech.net>:

> I agree with all of Stanislav's emails in this thread so far.
>
> On 12 December 2017 at 14:43, Nikita Popov <nikita.ppv@gmail.com> wrote:
> > On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev <smalyshev@gmail.co=
m
> >
> > wrote:
> >
> >> Hi!
> >>
> >> > The idea is to allow specifying declare directives for a whole
> library or
> >> > project using:
> >> >
> >> >     namespace_declare('Vendor\Lib', ['strict_types' =3D> 1]);
> >>
> >> I am not sure I like this. Namespace is a prefix to a class name.
> >> Anybody can declare a class with any name, and the side-effect that th=
ey
> >> would inherit some context, which is completely invisible and would
> >> magically exist somewhere globally, does not seem like a good idea to
> >> me. Moreover, what if something - like older version of the same libra=
ry
> >> or test or something like that - would have different idea about what
> >> that global state should be? How nice would it be if a piece of
> >> unrelated code could completely change how my code is interpreted? How
> >> nice would it be if whether it works or not would depend on in which
> >> order classes were loaded in this particular request?
> >>
> >
> > The way PHP works, it's not possible to have two versions of a library
> > loaded at the same time.
>
> Really?
> PHP does not even know what a "library" is. PHP sees files,
> directories and namespaces. But it does not know how to conceptualize
> any of this as a "library".
>
> With Composer you get the notion of a "package".
> In general, Composer would prevent you from using different versions
> of the same package.
> But you could manually download two versions of a package, and wire up
> the class loader in a way that it would load some classes from one
> version, and some classes from another version.
> E.g. if a class does not exist in version 2, load the class from
> version 1 instead.
>
> PHP as a language should not assume that someone is using Composer
> correctly.
>
> And even if we avoid two package versions coexisting: There could
> easily be two distinct packages that use the same namespace.
> We could discuss if this is a good idea, but it should not be the job
> of PHP as a language to make this situation difficult.
>
> >
> > There is no dependence on loading order. The implementation is careful =
to
> > ensure that the used declare state is consistent. It's not possible to
> call
> > namespace_declare() twice on the same namespace. It's not possible to
> first
> > load some files from a namespace, do the namespace_declare() call and
> then
> > load some more files. If a namespace_declare() call succeeds without
> > throwing an error, then that is the ground truth, without any dependenc=
e
> on
> > order or other calls.
>
> So by "is not possible", in fact you mean "will trigger an error".
>
> I imagine with Composer we would have to agree on a canonical file
> name where a namespace_declare() would be found.
> Maybe something like in src/Acme/Animal.namespace.php.
>
> The class loader would then have to make sure that this file is
> included before the first class from that namespace is included.
> Or alternatively, Composer init script would have to include all such
> files at the beginning of the process.
>
> If Composer (or whichever tool one wants to use) would include class
> file src/Acme/Animal/Cat.php without prior inclusion of the
> Animal.namespace.php, the class file would be interpreted without the
> desired setting.
> If the process then continues without ever including
> Animal.namespace.php, it will silently misbehave.
> If, however, Animal.namespace.php is included some time later in the
> process, then it would notice that something went wrong, and trigger
> an error.
>
>
If we're going to introduce someday a namespace file, then IMO it should
not be putted outside namespace folder.
For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php should have
namespace file in src/Acme/Aniimal/namespace.php
or even more src/Acme/Animal/ns.php
Why? Because users use PSR-4 so then they're src folder looks more like:
src/Cat.php <-- class Acme\Animal\Cat
src/ns.php <-- that should be then a place for namespace declare or even
function and constants.

Such namespace file can be a good place for namespace function and
constants declaration.
Also I think there is no need for another global function named
`namespace_declare` if we had namespace file
then we can utilise declare for that.
Lets imagine such syntax:

// src/Acme/Animal/ns.php
<?php

namespace Acme\Animal declare(strict_types=3D1,another_option=3D0);
const CAT =3D 1;
function createCat() : Cat {}

A good reason for that is that we're not using namespace as a string in
function call which is more IDE friendly to refactor.
There is another good reason for that - some code generators/container
compilers etc. whatever else
uses one file for more than one class that means there would be still an
option to pack few namespaces in one
separate file like for. eg:

<?php

namespace Acme\Animal declare(strict_types=3D1) {
    class Cat {}
}

namespace Another\Library { // <-- there is no declare for this namespace
    class SomeClass {}
}

These are just my thoughts and they can be completely nonsense.
I think it might be also a good place to provide more info in a future.
I know PHP is not Java9 and I'm gratefull for that, but IMHO sometimes
there are good concepts,
like module info in module-info.java file with module exports and requires
and info about what it provides at all.

> I haven't thought too carefully about whether having an option for the
> > explicit-send-by-ref feature *specifically* would be beneficial, but I
> > think it's very important to at least have the option on the table. Too
> > many issues in PHP cannot be solved for reasons of
> backwards-compatibility.
> > We need to have *some* way to evolve the language without BC breaks, an=
d
> I
> > think namespace-declares are an elegant way to do this.
>
>
> So if you want a setting for explicit-send-by-ref, why not do this per
> file, as we already do for strict_types?
>
> If at some day in the future we find that the declares become too
> verbose, we could bundle multiple declares into a new setting.
> E.g. something like "declare(php=3D8.1);" to combine all the declares
> that would be considered default in PHP 8.1.
>
> Or introduce some other shortcut like "<?php.8.1" instead of "<?php"
> opening tag.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--94eb2c1e9930e1495d056030dcae--