2017-12-13 6:04 GMT+01:00 Michał Brzuchalski <mic...@brzuchalski.com>:

>
>
> 2017-12-13 5:38 GMT+01:00 Michał Brzuchalski <mic...@brzuchalski.com>:
>
>>
>>
>> 2017-12-13 5:24 GMT+01:00 Andreas Hennings <andr...@dqxtech.net>:
>>
>>> On 13 December 2017 at 05:04, Michał Brzuchalski <mic...@brzuchalski.com>
>>> wrote:
>>> >
>>> > 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.
>>>
>>> You are right, my previous proposal src/Acme/Animal.namespace.php
>>> would not work universally.
>>>
>>> But your proposal, src/Acme/Animal/ns.php clashes with the class file
>>> for class \Acme\Animal\ns.
>>>
>>> We would need something other than NAME.php.
>>> E.g. src/Acme/Animal/ns.inc.php
>>>
>>
> Actually not true. `namespace` keyword is reserved and none class can have
> such name.
> This means this example couses a syntax error:
>
> <?php
> namespace Acme\Animals;
> class namespace {}
>
> That why we can assume we can utilise namespace.php file name.
> And also why not trying to include it on autoload call?
> For eg.
> <?php
>
> new Acme\Animal\Cat(); // tries to load $file = "src/Acme/Animal/Cat.php"
>
> // but prevoiusly tries to load
> require_once dirname($file) . DIRECTORY_SEPARATOR . 'namespace.php';
>
> It's bad because it';s magic, but the `namespace.php` filename is still
> available to use.
>
>
Andreas, we're touching namespaces which is a hard subject, but if I could
fly away with my thoughts
I'd propose to introduce something called for eg. a package and then
divide it's name in class/function/const name with a single colon, for eg.
Acme:Animal\Cat
which gives additional information about package which then declares
something and may be
a good start for future scoped declarations.

I've prepared a short gist to illustrate that
https://gist.github.com/brzuchal/352ffce2717648f0d43f2d5a0c4bfb7b

This solution doesn't require usage of Composer, but needs to pass an
aotuloader function a type to load.
There was a proposal on internal some time ago to pass additional parameter
to load function.


>
>>> But then Composer would still need to make sure that this file is
>>> always included before any class files from this directory.
>>> On language level we cannot assume that Composer is being used, and
>>> that it is being used correctly.
>>>
>>> So again this would be fragile.
>>>
>>> >
>>> > 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=1,another_option=0);
>>> > const CAT = 1;
>>> > function createCat() : Cat {}
>>>
>>> This means you are changing the meaning of existing declare() to apply
>>> to the entire namespace?
>>> Or to the entire directory?
>>>
>>>
>> To entire namespace just like:
>>
>> <?php declare(strict_types=0);
>>
>> namespace_declare('Acme\Animal', [
>>     'strict_types' => 1,
>>     'dynamic_object_properties' => 0,
>>     ...
>> ]);
>>
>> namespace Acme\Animal declare(
>>     strict_types=1,
>>     dynamic_object_properties=0
>> ); // <-- this works same as namespace_declare call above
>>
>> namespace Acme\Machines {
>>     // here we have strict_types=0 turned off
>> }
>>
>>
>>> Or maybe the difference here is that there is no semicolon directly
>>> after the namespace declaration?
>>>
>>> I am not convinced by this syntax.
>>> But even if we would find a good syntax, the behavioral problems
>>> pointed out by Stanislav still apply.
>>>
>>
>>
>>
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> about.me/brzuchal
>> brzuchalski.com
>>
>
>
>
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Reply via email to