Re: [RFC] Namespace-scoped declares, again

From: Date: Wed, 14 Aug 2019 09:01:27 +0000
Subject: Re: [RFC] Namespace-scoped declares, again
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-106582@lists.php.net to get a copy of this message
On 14/08/2019 07:45, Michał Brzuchalski wrote:
It doesn't have to be a new syntax if we agree to put package definiction in sort of separate configuration file.
With the exception of INI files, all your examples are new syntax, as far as the internal mechanisms in PHP are concerned. They have the advantage of not inventing our own, but the disadvantage of needing our parser to handle all the ways people might write them (particularly true for YAML).
That way it would prevent to mix normal PHP code with package definition, cause every possible PHP syntax we would agree, opens the door to add something more to that file, for eg.: # package.php <?php declare package MyVendor\MyLibrary { strict_types = 1, encoding = "UTF-8" } function foo() {}
I don't see this as a problem. Right now, PHP doesn't care how many files you put your code in. As far as I know, you could concatenate the entirety of Laravel into one PHP file, and applications would not be able to tell the difference. Similarly, you could put the whole thing in a database and use eval() to execute it without touching any files. In the same way, we can have a package definition not as a configuration file, but as a piece of PHP code that needs to have been executed. In practice, people wouldn't write what you have there for the same reason they don't write this: # foo.php <?php class Foo { } function bar() {} I don't think we need to hold people's hand to prevent that. I think what attracts me to this idea is precisely that it doesn't require much extra machinery. We could even use the trick that PHPStorm uses for metadata stubs [1], and make the package definition look like valid executable PHP, but never actually execute it: package Foo {
    const declare = [
       'strict_types' => 1,
       'strict_operators' => 1
    ];
} That way, we can probably reuse the whole parser infrastructure, and it looks entirely natural to a PHP programmer. [1]: https://blog.jetbrains.com/phpstorm/2019/02/new-phpstorm-meta-php-features/ -- Rowan Collins [IMSoP]

« previous php.internals (#106582) next »