On 14/08/2019 10:27, Michał Brzuchalski wrote:
But that's conflicting with you above idea for package definition like
that:
<?php
package MyVendorMyLibrary {
declare(strict_types = 1);
}
That's not what I'm suggesting; perhaps my example could have been
clearer. I envisage two new keywords:
- To put some code in a package, you would write "package Foo;" at the
top of a file, or "package Foo { }" around a block, in the same way you
can do now for namespaces and declare() statements.
- To define a package before it is used, you would write "packagedef Foo
{ }" around some block of pseudo-PHP that defined the options for that
package. That might involve using declare() directly, or might just be
an array that defines the options.
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.
As I said in another reply, this is only the same change that needed to
be made to support "trait" alongside "class" and "interface", or would
be needed to support "enum" or "struct". The userland part of the
autoloader already doesn't know which of those it's looking for, so the
only constraint is that the names can't collide, so you couldn't name a
package the same thing as a class.
There are other problems with autoloading functions and constants, but
the relevant point is that you can define function foo() {} and class
foo {} in the same namespace; as long as you couldn't also have a
separate package foo{}, it could share the same autoloader as classes,
interfaces, and traits.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
