Re: [RFC] Namespace-scoped declares, again

> On 14 Aug 2019, at 00:05, Rowan Collins <rowan.collins@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