On Wed, Jul 3, 2024 at 7:49 AM Aleksander Machniak <a...@alec.pl> wrote:
> On 3.07.2024 07:32, Richard Miles wrote: > > What if php implicitly prepended namespaces with the composer package > version? > > If two incompatible versions are required, the composer downloads both. > Enabled/Disabled with flag? > > While we're brainstorming... What if something like this would be possible? > > include $file with (strict_types=1, scope=$prefix); > > Composer would be able to do something useful with that, I suppose. > > I would prefer to leave sleeping dogs where they lie - that is not change how include, include_once, require and require_once work. For one, code imports are never optional, so the two include statements are NEVER appropriate. Second, symbol definitions are never to be done twice, so require is NEVER appropriate. That leaves require_once, and having it behave differently from its siblings is asking for confusion. Hence the reason I'd rather dispense with them entirely and move to a new import mechanism entirely - import. And since it's a new import mechanism it could clean things up that cannot be cleaned any other way. I've tried to stay away from that in the last few emails, but it is there. At a minimum in my opinion, import should be a "code first" importer and not require the file to be imported use <?php to get into code mode. If this means using a separate extension for these files such as phm so that the IDE's can figure it out (and so can users at a glance) so be it. But the behavior of the import statement is parallel to the package issue itself - that is import files could be nothing special and the package mechanism would still be a feature worth targetting.
