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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
