> On 14 Aug 2019, at 00:05, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
>> On 13/08/2019 12:01, Mark Randall wrote:
>>> On 13/08/2019 10:02, Rowan Collins wrote:
>>> I really like this approach. It allows a package definition file to exist,
>>> without either the language or the header of each file having to define its
>>> location.
>>
>> #
>> # File: /lib/company/project1/a/b/MyClass.php
>> #
>>
>> <?php
>>
>> declare_import(company[:label]);
>>
>> namespace company/project1/a/b;
>>
>> ...
>>
>>
>> #
>> # File: /lib/company/__nsmeta.php
>> #
>>
>> <?php
>>
>> namespace company;
>>
>> namespace_declare [:label] {
>> strict_types=1;
>> strict_operators=1;
>> upgrade_errors_to_exceptions=E_ALL;
>> }
>>
>> final class __nsmeta {
>> /* does nothing except be findable by the autoloader */
>> /* and defaults to private constructor so it can't be used */
>> }
>
>
> This seems to be more complicated than Nicolas's version, and involve much
> more special magic, like the name __nsmeta, and the class that does nothing.
> I'm also not clear on how you're picturing the relationship between
> namespaces and packages.
>
> The way I understood the suggestion, you'd end up with something more like
> this, which feels much simpler and cleaner:
>
> #
> # File: /lib/company/project1/a/b/MyClass.php
> #
>
> <?php
>
> declare(package=company/project1);
> // or with a new keyword
> package company/project1;
>
> namespace company/project1/a/b;
>
> ...
>
>
> #
> # File: /lib/company/project1.php
> #
>
> <?php
>
> namespace company;
>
> class project1 extends \PHP\Package {
> public function getParserDirectives() {
> return [
> 'strict_types' => 1,
> 'strict_operators' => 1,
> 'upgrade_errors_to_exceptions' => E_ALL
> ];
> }
> }
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I think this approach is easier to follow (less magic) but has a (small)
potential for conflict with existing code that may then require renaming or
more (eg if a class existed with that proposed name, and is either a singleton
and/or already extends another class).
Is it feasible to instead require the class implements an interface that
defines a static method?
Building on that, could the concept of “do something to initialise this
package” be made more generic: when a file declares it’s a member of a given
package, the static method on the class that matches the package name is
called, and it’s up to the developer what it does in that method. That would of
course also then require a new function to set the declares with package scope
to be useful for this particular problem, but it also allows more control and
power for the concept of packages in general.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
