On Mon, Aug 12, 2019, at 3:26 AM, Nikita Popov wrote: > On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote:
> > I've read discussions about the notion of a "package" and the way we > > should define its boundaries. > > What about the following? > > > > Individual files could declare their package using this style: > > <?php declare(package=MyVendor\MyPackage); > > > > That would be enough to group a set of files together and make them share > > eg some private classes, some optional PHP behaviors, etc. > > > > The right side "MyVendor\MyPackage" would also be a FQCN that PHP would > > autoload as a regular class. The corresponding class would then be the > > place where ppl would declare the engine behavior they want for their > > package (strict types, etc). To enforce this, the engine could require that > > the "MyPackage" class implements some interface/extend some base abstract > > class. > > > > Of course, one could hijack a package and declare an unrelated file as > > part of it, but I don't think that's an issue: the situation is the same as > > for namespaces, where one can hijack a third party vendor namespace. In > > practice, it proved not being an issue, and the original author's intent is > > clear: "this is my namespace/package, if you mess with it, fine, but you're > > on your own". > > > > Nicolas > > > > FTR I've created a draft-implementation for a package system here: > https://github.com/php/php-src/pull/4490 > > It uses a slightly different approach in that it keeps the package name a > string (that should usually match the Composer package name) and uses a > function to register the package. > > The main annoyance is that this requires declaring the package in every > file, something I would like to avoid. An alternative I played with is to > allow specifying the package at include time, which would allow the > autoloader to specify which package a file is part. However, while this is > more ergonomic for the user, I'm afraid that this will make static analysis > & IDE scenarios problematic, because they will not be able to easily know > what the package is in cases that fall outside convention. So in the end, > an explicit per-file package declaration may be the best we can do. > > Nikita I don't think declaring the package in each file is necessarily bad. Every language I've worked in either has you declare a package explicitly or implies it off of the file system and you don't get any say in the matter. Of the two, I prefer the former. My concern with using a function call is that it introduces/increases the potential for a file to say it uses a namespace that isn't yet defined. What happens then? Fatal? Autoload trigger? The code ends up un-packaged silently? (Please not the last one.) I don't feel like "it's Composer's problem" is a good answer here. Making the package name be a class name at least makes autoloading a natural and well understood way to handle the lookup. There may be other benefits to using a class/methods to define a package, or possibly even downsides; I'm not sure there. More research needed. Same for avoiding package name collisions; "it's FIG's problem" may be an answer, but it seems like a poor one. In practice I'd expect package definitions to be the obvious example of the preloader, but there will always be cases where the preloader is not available or cannot be used so we need to consider the performance impact of registering packages in every request. Has anyone done in-depth research into how other languages handle packages, and what advantages packages would have over just our existing nested namespaces? I feel like there's ample prior art here that we should not ignore. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
