On 13/12/2017 07:12, Michał Brzuchalski wrote:
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
My thoughts were actually going along the same lines: basically, the
current implementation of namespaces is, I think by design, very
conservative in what a namespace represents. A namespace doesn't have
any identity, and doesn't have any codified structure, it's just a
shorthand for referring to similarly named classes (plus functions and
constants).
There are several things that I think would feel more natural with
"packages" than namespaces as they exist today:
- Declare directives, as discussed here
- Visibility modifiers, e.g. a "private class", accessible only within
its package
- Per-package autoloaders, that only get called for classes in that
package, rather than a global autoloader which parses out the prefixes
it's interested in
- An autoloader callback that fires once for each package, to setup
these options
Another difference is that namespaces tend to form deep hierarchies, but
you're unlikely to set options at every level of the hierarchy. For
instance, you probably don't want to set strict_types on for
Acme\MyPackage\Input but off for Acme\MyPackage\Output. So a separate
syntax to mark which level is the "package" would reduce the number of
places a setting could be set, which would reduce the number of places
you'd need to look - a bit like having Apache settings in a VirtualHost
for the whole site, rather than .htaccess files in every directory.
All that being said, I'm not 100% convinced this is solving a real
problem. Yes, the option has to be set in every file, but that's because
it effects the way that file is compiled, and the compiler sees one file
at a time. The same applies to the "namespace" directive, which you
might otherwise set against a particular directory. I don't see a
pressing need to add the complexity.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
