śr., 14 sie 2019 o 11:01 Rowan Collins <rowan.coll...@gmail.com> napisał(a):
> 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.
>
>
That is true but not if there are any declare statements. If so it could
IMO work only like that:
<?php
package MyVendorMyLibrary {
declare(strict_types = 1);
class Foo {}
namespace FooBar {
class Baz {}
}
}
package Other\Library {
declare(strict_types = 0);
declare(encoding = "UTF-8");
class Awesome {}
}
This way declare directives could be set only once per package.
But that's conflicting with you above idea for package definition like that:
<?php
package MyVendorMyLibrary {
declare(strict_types = 1);
}
I see no option to concatenate all source files any longer then?
Cause when PHP would know if it has to create package definition and not
look for it
and load it through autoload machinery?
> 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
> ];
> }
>
How could that know when need look for package definition?
Example:
# src/Foo.php
<?php
package MyVendor\MyLibrary;
class Foo {}
You suggest that it would trigger autoload to load "MyVendor\MyPackage"
but current autoload machinery is able to load only classes,
not even functions or consts! cause it gets the only class name now.
It would need to be changed anyway.
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
