Hi internals!

Some time ago I introduced the following proposal for namespace-scoped
declares:

https://wiki.php.net/rfc/namespace_scoped_declares

The idea is to allow specifying declare directives for a whole library or
project using:

namespace_declare('Vendor\Lib', ['strict_types' => 1]);

I've finally gotten around to implementing this proposal (
https://github.com/php/php-src/pull/2972) and would like to move forward
with it.

The reason why I'm picking it up again is some feedback I received for the
explicit call-time send-by-ref proposal. The main objection seems to be
that the feature has limited usefulness if it's optional rather than
required, because you still can't be sure that something is a by-value
pass, just because no & is present. At the same time, we can't make this
required anytime soon due to the large BC impact.

Namespace-scoped declares are perfectly suited to resolve this problem. We
can introduce a require_explicit_send_by_ref declare directive to make the
call-site annotation required, and libraries/projects can easily opt-in to
it using namespace_declare(). There would be no BC impact, while at the
same time projects could benefit from the additional clarity and
performance improvements immediately.

Thanks,
Nikita

Hi internals!

Some time ago I introduced the following proposal for namespace-scoped
declares:

https://wiki.php.net/rfc/namespace_scoped_declares

The idea is to allow specifying declare directives for a whole library or
project using:

namespace_declare('Vendor\Lib', ['strict_types' => 1]);

I've finally gotten around to implementing this proposal (
https://github.com/php/php-src/pull/2972) and would like to move forward
with it.

The reason why I'm picking it up again is some feedback I received for the
explicit call-time send-by-ref proposal. The main objection seems to be
that the feature has limited usefulness if it's optional rather than
required, because you still can't be sure that something is a by-value
pass, just because no & is present. At the same time, we can't make this
required anytime soon due to the large BC impact.

Namespace-scoped declares are perfectly suited to resolve this problem. We
can introduce a require_explicit_send_by_ref declare directive to make the
call-site annotation required, and libraries/projects can easily opt-in to
it using namespace_declare(). There would be no BC impact, while at the
same time projects could benefit from the additional clarity and
performance improvements immediately.

Thanks,
Nikita

I plan to pick up this proposal again. I think the motivation here has
become more pressing in the meantime. The strict_operators proposal is
under discussion, and Rowan's "locked classes" essentially concluded with
"doing this with a declare is better". I also think that this proposal will
be helpful for the explicit call-site by-reference passing RFC.

Based on the received feedback, I plan to change this proposal from being
"namespace-scoped" to being "directory-scoped" instead. This should both
resolve some of the concerns and make the proposal more flexible: Not all
code sharing the same namespace is part of the same package (multiple
packages may have classes in the same namespace), or not of the same type
(code and tests may share a namespace) and sometimes people use incorrect
namespaces out of ignorance (e.g. place their own Doctrine models under the
Doctrine namespace). Making the declares apply to a directory avoids these
issues.

Nikita

...

Based on the received feedback, I plan to change this proposal from being
"namespace-scoped" to being "directory-scoped" instead

...

I think that's a better approach.

But please consider doing this without adding another global function that
defines more global (compiler) state?

If it's going to be directory-scoped, using some kind of project root file,
in my opinion, is the more traditional way to declare directory-scoped
boundaries.

For example, if you could just put a "php.json" file in the root of your
namespace folder, this becomes very easy to spot next to your ".gitignore",
"composer.json", "package.json", "tsconfig.json" and any other well-known
project configuration files.

Finding these in the root of any project/library is pretty intuitive -
poking through bootstrapping scripts for a global function call, meh, not
so much.

(This file could be used to declare other repetitive things too - for one,
why is the declare() situation any different from having to repeat a
namespace declaration in every file? This is just another global setting
that could just as well be declared once in a project root file. If this
file were parsable or reflectable by e.g. Composer, this could probably be
used to make the "autoload" section in Composer optional, for one.)

(You could expand upon this feature in the future to add other compiler
options - for instance, toggling global functions, which would allow for
things like correcting inconsistent argument order in the standard
libraries, toggling incompatible language features, toggling improved
defaults for certain functions, a proper strict type-checking mode at some
point in the future, etc...)

Based on the received feedback, I plan to change this proposal from being
"namespace-scoped" to being "directory-scoped" instead

Personally I'm not a huge fan of using implicit hierarchical directories
for managing defines.

It's certainly better than global state functions, but in general I
don't feel comfortable with the idea that an arbitrary file can effect
the behaviour of the VM for particular files that does not directly
reference it.

Obviously there's lots of functions that do that, set_error_handler etc,
but I think it is best avoided wherever possible.

I think what the situation calls for is the PHP equivalent of #include -
we need to be able to explicitly import the definitions from another file.

====== MyProject\Models\Test\SomeClass.php =======

<?php
import_declares(\MyProject);

namespace MyProject\Models\Test

class SomeClass {
   public function action(&$ref) { ... }
}

====== MyProject\declares.inc =======

<?php
declare(strict_types=1)
declare(call_site_references=1)
declare(global_function_fallback=0)

This forms an explicit link between the file and the declarations.

Clearly the question is "how to locate that file" as we don't want to
return to the days of having to add relative file paths to every file.

An option which immediately comes to mind would be a new autoloader
routine that maps namespaces to PSR4 physical directories. Sounds like a
job for composer tbh so userland workload would be limited for projects
using modern workflows.

This would of course be dependent on if the compiler stage has the
ability to branch off and call an autoloader the first time it
encounters the import_declares.

Just my 2 pence worth.

--
Mark Randall

Hi!

I plan to pick up this proposal again. I think the motivation here has
become more pressing in the meantime. The strict_operators proposal is
under discussion, and Rowan's "locked classes" essentially concluded with
"doing this with a declare is better". I also think that this proposal will
be helpful for the explicit call-site by-reference passing RFC.

I think it's a wrong way to make semantics of the language to be
different in different libraries. We add one option, than another, than
another, and soon we have 512 variants of the language, all slightly
different, and you have to keep track which one you are dealing with on
each file, and God forbid you move a piece of code from one library to
another, you have to rewrite half of it because it was written in PHP
#243 but this library is actually PHP #116.

I know there is not a consensus about usage of some newly proposed
language features. I think introducing this kind of fragmentation to
deal with it is exactly wrong way to deal with it. It leads to code from
different codebases being incompatible with each other on source level
(even if they work together at runtime). We've decided not to do INI
options to change language behavior, and I think we should also not make
declare() options to change language behavior, because they are -
especially when applying to more than local file - essentially low-grade
INI options. They create non-local context that changes behavior of the
language, and they make it impossible, reading the local code, to know
what it actually means and what would happen if you run it.
I think it's much better for the language not to have some features than
to fragment the language and make it incompatible with itself.

Based on the received feedback, I plan to change this proposal from being
"namespace-scoped" to being "directory-scoped" instead. This should both

I don't think it improves much, in my opinion, and it also introduces
hard dependency in the language on specific placing of files and
directories - i.e. if you move file on the filesystem, it can actually
work differently, which was never the case before. Having concepts like
filenames change the core functionality of the language looks to me like
an example of leaky abstraction and a hack which may solve a particular
problem now but at the cost of making the whole design more messy and
introducing more problems in the future.
I said before that moving code between libraries in this setup could
break it - but with this change, even copying a file to a different
directory may break it! Moreover, change in one part of project,
changing some behavioral option, would propagate and influence code
about which the changer may not even know (e.g. if parts of the project
are developed and tested separately and only deployed in final form on a
production filesystem).
This looks like potential to create an environment that is very hard to
navigate and keep straight which of the options is in play for each
peace of code.

Stas Malyshev
smalyshev@gmail.com

The introduction in this RFC says "A common complaint is that this directive has to be specified in every single file.". I think people will complain import_declares if we follow your design.

Regards,
CHU Zhaowei

-----Original Message-----
From: Mark Randall markyr@gmail.com
Sent: Sunday, July 28, 2019 6:54 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

Based on the received feedback, I plan to change this proposal from
being "namespace-scoped" to being "directory-scoped" instead

Personally I'm not a huge fan of using implicit hierarchical directories for
managing defines.

It's certainly better than global state functions, but in general I don't feel
comfortable with the idea that an arbitrary file can effect the behaviour of the
VM for particular files that does not directly reference it.

Obviously there's lots of functions that do that, set_error_handler etc, but I
think it is best avoided wherever possible.

I think what the situation calls for is the PHP equivalent of #include - we need to
be able to explicitly import the definitions from another file.

====== MyProject\Models\Test\SomeClass.php ======= ``` <?php
import_declares(\MyProject);

namespace MyProject\Models\Test

class SomeClass {
public function action(&$ref) { ... } } ```

====== MyProject\declares.inc =======

<?php
declare(strict_types=1)
declare(call_site_references=1)
declare(global_function_fallback=0)

This forms an explicit link between the file and the declarations.

Clearly the question is "how to locate that file" as we don't want to return to the
days of having to add relative file paths to every file.

An option which immediately comes to mind would be a new autoloader routine
that maps namespaces to PSR4 physical directories. Sounds like a job for
composer tbh so userland workload would be limited for projects using modern
workflows.

This would of course be dependent on if the compiler stage has the ability to
branch off and call an autoloader the first time it encounters the
import_declares.

Just my 2 pence worth.

--
Mark Randall

--
To unsubscribe, visit:
http://www.php.net/unsub.php

Based on the received feedback, I plan to change this proposal from
being
"namespace-scoped" to being "directory-scoped" instead. This should
both
resolve some of the concerns and make the proposal more flexible: Not
all
code sharing the same namespace is part of the same package (multiple
packages may have classes in the same namespace)

I think the word "package" here is significant, because all the other variants of this proposal come down to "how can we best emulate package/module support":

• the original namespace form assumes that some level of the namespace hierarchy represents a package
• the proposal to use a directory assumes that some structure on disk represents a package
• Mark's alternative using an explicit include allows every file to say it's part of some package

I think it would be better to skip these workarounds, and define a package directly. The differences I see between package and namespace are:

1. Packages should be non-hierarchical. Perhaps most simply a package name could have exactly two parts, like in composer, so it's clear that there is no implied relationship between two packages.

2. A package should be explicitly declared before first use, probably in a separate file. This definition would have scoped declares, and could also have autoload and preload definitions. Or perhaps a package would always be eagerly loaded, allowing us to do more cross-file analysis at compile-time.

Obviously, there's a lot to figure out here. Do we define where the package definition lives on disk, or require the user to configure it in some way? Does a package name form the prefix for namespaces within that package, or can a package contain definitions for any namespace? However, I think we should make these design decisions, rather than letting an easy implementation lead us somewhere we'll regret later.

I do also share the concern that a proliferation of package options would make the language harder to understand. Part of the motivation for removing short open tags seems to be to make the language more consistent. The ability for a package to configure the compiler as its author intended is certainly better than having to test every combination, but we need to think very carefully about what options we add.

Regards,

Rowan Collins
[IMSoP]

We've decided not to do INI options to change language behavior,...
because they are - especially when applying to more than local
file - essentially low-grade INI options

I don't agree. What's being proposed are not low-grade INI options.

The problems with ini settings is that:

• Different libraries could require different settings.
• There was no way to manage the settings individually per library.

Those problems do not apply to the proposed RFC.

As we've seen with the declare for strict types, libraries that want
to have strict mode, and libraries that want to have more type
juggling, are perfectly fine to live alongside each other, and can be
used just fine.

I think it's a wrong way to make semantics of the language to be
different in different libraries.

I can't agree.

I look at the success of how strict types was brought in, in a way
that allowed for zero breaking changes for existing code, and think it
was a massively successful way of improving the language without
causing problems.

I can't understand why someone would make the argument that evolving
the language like this is a bad thing.

This looks like potential to create an environment that is
very hard to navigate and keep straight which of the options
is in play for each peace of code.

You're saying very negative things about a feature you would not have to use.

There have been multiple problems/features over the years that would
have been more solvable is we had this RFC implemented.

It's fine that you're not convinced that this is a great idea, but
please can you stop making the argument that because you don't want to
use a feature, no-one should be allowed to use it?

cheers
Dan
Ack

Hi!

As we've seen with the declare for strict types, libraries that want
to have strict mode, and libraries that want to have more type
juggling, are perfectly fine to live alongside each other, and can be
used just fine.

You are assuming all the code is neatly organized in "libraries" that
are closed packages that never intersect, never exchange code and can be
completely isolated from one another. This may be the case in some
applications, but it's in no way universal and there's a lot of PHP code
that does not look like that.

I can't understand why someone would make the argument that evolving
the language like this is a bad thing.

It's not evolving the language, it's splitting the language into a
myriad of mutually incompatible sub-languages, so each piece of code has
its own unique bitmask of settings it works with. Moreover, even that
bitmask is not local - when you're reading the code, you'd have to check
all encompassing filesystem hierarchy (with current idea) to see where
the options bitmask if defined for every particular piece of code.

You're saying very negative things about a feature you would not have to use.

I think it's time to retire the argument of "you don't have to use it".
It's not some function that you don't have to call (and BTW I am seeing
a massive push to eliminate those for some reason, and never hear that
argument there!). It's a language level feature. PHP is an ecosystem,
and if you introduce the feature, everybody is influenced by it, because
now you have to be aware of the whole bitmask of options and consider
every time which bitmask of options a particular code piece is
requiring. If it was an ecosystem where code is compiled into binary
packages, like C or Java, it won't be such a big deal - you just use the
compiled package and never look and the code that produced it and
couldn't be happier. But in an open-source ecosystem what encourages
exchanging actual source code, this kind of language fragmentation is bad.

It's fine that you're not convinced that this is a great idea, but
please can you stop making the argument that because you don't want to
use a feature, no-one should be allowed to use it?

Did you actually try to read my argument, of just decided to strawman it
from the start? I never said anything like that. I said this feature is
bad because it creates fragmentation in the language, not because "I
don't want to use it". Please, at least try to address my arguments. I
am spelling them out pretty verbosely, no need to put words in my mouth.

--
Stas Malyshev
smalyshev@gmail.com

I look at the success of how strict types was brought in, in a way
that allowed for zero breaking changes for existing code, and think it
was a massively successful way of improving the language without
causing problems.

I think it's a) very early and b) very subjective to call that decision "massively successful". I have had conversations online and in person asking both why there are two modes, and why the mode can't be selected globally.

It was a classic compromise that neither side of the debate hated, but neither really loved either, and the subtleties of how each mode works are likely to be sources of confusion for years to come. I am far from convinced that it is a model we should enthusiastically seek to repeat.

Regards,

Rowan Collins
[IMSoP]

Hi!

I look at the success of how strict types was brought in, in a way

It was a classic compromise that neither side of the debate hated,
but neither really loved either, and the subtleties of how each mode
works are likely to be sources of confusion for years to come. I am
far from convinced that it is a model we should enthusiastically seek
to repeat.

It was OK as one local compromise, but I don't think it's OK as door
opening to create unlimited number of options that modify any language
behavior in any file and fragment the language. One switch is two
options, not ideal but manageable. 10 switches is 1024 options. Not
nearly manageable.

I am not sure what "success" is there - is there any evidence of strict
mode being widely embraced by companies with large legacy code base? By
large frameworks used by thousands or millions, and successfully
deployed and maintained in mixed settings environments?

I think I agree - it's a bit early to proclaim "success". There's no
visible disaster (that I think would result from pushing through
all-strict mode without BC provisions) but I am not sure what base for
proclaiming triumph there is.

Stas Malyshev
smalyshev@gmail.com

Hi,

niedz., 28 lip 2019 o 05:17 Stanislav Malyshev smalyshev@gmail.com
napisał(a):

Based on the received feedback, I plan to change this proposal from being
"namespace-scoped" to being "directory-scoped" instead. This should both

I don't think it improves much, in my opinion, and it also introduces
hard dependency in the language on specific placing of files and
directories - i.e. if you move file on the filesystem, it can actually
work differently, which was never the case before. Having concepts like
filenames change the core functionality of the language looks to me like
an example of leaky abstraction and a hack which may solve a particular
problem now but at the cost of making the whole design more messy and
introducing more problems in the future.

IMHO it would be impossible to find out what are the boundaries of
namespace scope
or package scope (whatever you call that) symbols without a root namespace
file.

I can imagine some can use explicit require to load library class to skip
scoped declares,
autoloads or whatever lands there.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Hi Rowan,

niedz., 28 lip 2019 o 12:15 Rowan Collins rowan.collins@gmail.com
napisał(a):

1. Packages should be non-hierarchical. Perhaps most simply a package name
   could have exactly two parts, like in composer, so it's clear that there is
   no implied relationship between two packages.

IMO this would create a lot of problems cause name in Composer Package
doesn't reflect used namespace declared in autoload, for eg.

Composer package name => used namespace

ocramius/package-version => PackageVersions
doctrine/collections => Doctrine\Common\Collections
symfony/console => Symfony\Component\Console\

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

On Tue, Jul 30, 2019 at 10:12 AM Michał Brzuchalski michal@brzuchalski.com
wrote:

IMO this would create a lot of problems cause name in Composer Package
doesn't reflect used namespace declared in autoload, for eg.

Composer package name => used namespace

ocramius/package-version => PackageVersions
doctrine/collections => Doctrine\Common\Collections
symfony/console => Symfony\Component\Console\

--
regards / pozdrawiam,

Michał Brzuchalski

Hi,

This might also cause issues in scenarios where packages would register
autoloading of a conflicting namespace. If for some reason the namespace
clashes with a vendor, or vica versa, or a vendor package "hides" an
additional namespace in the package and overrides the declares that way, it
could cause a lot of problems.

Would it be an idea to first establish the concept of a package within PHP,
rather than deducting it based off a namespace? If packages would be a
thing in PHP, other than just a namespace, package private could also be
implemented as visibility modifier for inheritance and class visibility.

Regards,
Lynn van der Berg

On Tue, 30 Jul 2019 at 09:12, Michał Brzuchalski michal@brzuchalski.com
wrote:

1. Packages should be non-hierarchical. Perhaps most simply a package name

could have exactly two parts, like in composer, so it's clear that there is
no implied relationship between two packages.

IMO this would create a lot of problems cause name in Composer Package
doesn't reflect used namespace declared in autoload

I'm not saying the package name has to match the composer name, just that
the format might be similar; and I explicitly left the question open of how
package names would relate to namespaces. It might be sensible to align the
package/module name with one or other of the existing two naming schemes,
but it's certainly not essential; names in Composer are essentially
arbitrary anyway, not visible at all at run-time.

Would it be an idea to first establish the concept of a package within
PHP, rather than deducting it based off a namespace? If packages would be a
thing in PHP, other than just a namespace, package private could also be
implemented as visibility modifier for inheritance and class visibility.

I think there's some confusion here, because establishing the concept of a
package as separate from a namespace is exactly what I proposed.

Here's a previous message (technically in the same thread, but from 18
months ago) where I also mentioned class visibility:
https://externals.io/message/101323#101390

Regards,

Rowan Collins
[IMSoP]

Hi Rowan,

wt., 30 lip 2019 o 10:48 Rowan Collins rowan.collins@gmail.com napisał(a):

I think there's some confusion here, because establishing the concept of a
package as separate from a namespace is exactly what I proposed.

Here's a previous message (technically in the same thread, but from 18
months ago) where I also mentioned class visibility:
https://externals.io/message/101323#101390

Was thinking about similar, a package with own identity and a way to
declare autoload and other stuff.
Was even thinking it could use a double colon which I've proposed way back
in the same thread and
with a delimiter in name all related symbols could be stored in package
individual symbol tables,
it won't collide with namespaced and global ones and would be easier to
detect if tried to use an internal symbol
in another context like other package or in global code.
It could introduce a few more keywords like:

• "package" - for declaring package name and declares,
• "export" - for explicit declare of publicly available symbols which then
  could be detectable etc. for visibility features,
• "expect" - for explicit declare of required dependencies

Last two are for future features and the first one could be enough for
shaping how it could look like.
For eg. some of my thoughts
https://gist.github.com/brzuchal/c45010f0dd20642b470eeee8b9c56c5f

I know it's out of the main topic but IMO we should start another one and
I'm pretty sure I've mentioned that earlier.
If we wanna shape package for PHP then the separate discussion could be a
good idea.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Thanks everyone for your responses!

I think the discussion resolves around two primary concerns, so let me
address them in turn.

The first is the general approach of using declares as a language-evolution
mechanism. The concern here is that each additional declare fragments the
language and increases the number of combinations of different options
there are.

What I ultimately want to achieve here is a way to evolve the language and
fix long-standing issues without breaking backwards compatibility or
causing ecosystem fragmentation. The only way we currently have to address
(nowadays) undesirable behavior is through deprecation and subsequent
removal. As people like to regularly remind me, this has a high cost on the
ecosystem, because millions of codebases that were running without a glitch
need to be updated, which not only takes a lot of effort, but also delays
adoption of new PHP versions for everyone. As such, the "deprecation and
removal" approach has to work over long time-frames and is only really
applicable to rather "minor" issues in the first place.

If we want to evolve the language without breaking backwards compatibility,
we need to provide a way for gradual migration of the ecosystem: A library
should be able to opt-in to breaking changes, while remaining usable by
downstream consumers. Conversely, an application should be able to opt-in
to breaking changes, while still being able to use an older library.

To achieve this, I believe it is unavoidable to have some kind of
mechanism to affect language-behavior on a per-library/project level. Of
course, the devil tends to be in the details...

What this RFC originally proposed is a fine-grained approach, where
individual changes are controlled by separate declare directives. However,
this is not the only possibility: As has been recently popularized with
Rust editions (https://doc.rust-lang.org/edition-guide/editions/index.html),
a coarse-grained approach where multiple changes have to be enabled
together as part of an "edition" is also possible.

The advantage of the coarse-grained "edition" approach is that it avoids a
combinatorial explosion of options: It's all or nothing, and it is easier
to keep in mind that a project uses "PHP 2020" rather than some specific
combination of declares.

The advantage of a fine-grained approach is that is also allows a
fine-grained migration. As a statically-typed language, Rust can provide
fairly reliable tooling to perform edition migrations. While such tooling
also exists for PHP (e.g. Rector), it does not have the same level of
reliability, especially for codebases that do not make pervasive use of
type annotations. Fine-grained declares allow a code-base to be updated one
step at a time.

It is possible to combine both approaches by providing both fine-grained
control and an overall "edition" that enables a larger set of language
declares. The end goal should be to move to the next edition, but
individual declares may be used during the migration, or to opt-out a
section of code. This is probably my preferred approach.

I should probably also highlight that this is somewhat different from the
existing strict_types directive: strict_types was only in part a mechanism
to control BC breakage (with regard to internal functions), but to a large
part exists because we couldn't agree on which semantics are preferable.

This is not what I'm going for here. I don't want declares to becomes a way
to resolve disagreements by just providing both options. Instead a declare
represents a change that we want to make and that codebases should make
eventually, but that is opt-in to maintain backwards compatibility and
library interoperability.

The second concern is around the technical details of opting-in to
BC-breaking language changes on the library level. Here is an overview of
some proposals that have been made:

1. Keep declares per-file. This is clearly incompatible with any
   fine-grained (or optionally fine-grained) approach, because declares have
   to be replicated across hundreds of files. I think this is a bad choice
   also for a coarse-grained approach (or even for the existing strict_types
   directive), because in all cases I've seen people want to enable the option
   for the whole library, not individual files.

Replicating declares per-file is error prone (I regularly forget to add
strict_types declarations to newly created files) and complicates the
mental model of the programmer. While ostensibly per-file declares make
things explicit, I think the reality is that nobody actually double-checks
declares in each file they open and will instead assume that the project
default holds.

2. Support per-namespace declares. This is what I originally proposed. This
   is based on the premise that a library will usually correspond to a
   namespace. This approach has been extensively discussed in this thread -- I
   think the main issue is that the premise just doesn't reliably hold up in
   practice, e.g. because multiple packages publish under the same namespace.

3. Support per-directory declares, which is the direction I was planning to
   explore next. This is based on the premise that all library files are part
   of some top-level directory, which I think is a fairly safe premise (note
   that the "directory" could also be a phar file).

The actual intended use (similar to the namespace-based variant) is that
people will specify their declares in the composer.json file, and composer
then includes a call to declare_directory() or similar as part of the
autoloader. Projects not using composer have the choice of issuing an
explicit call.

4. Specify declares in a special file, similar to how INI directives are
   declared. The suggestion here has been that PHP could scan the path of an
   included file upwards to find a declares.json (or similar).

The main advantage I see here (over a declare_directory() function) is that
there are no loading order issues. declare_directory() needs to be called
before any files from that directory have been included (which is part of
why an integration into the composer autoloader is useful), while for a
separate and implicitly processed file this falls out naturally.

Apart from that, I'm not a big fan of this proposal, mostly because of the
implicit loading it entails. I also don't think that having one more
configuration file for this buys us something over declaring things in
composer.json.

5. Introduce a first-class module/package concept and support per-package
   declares. This is arguably the closest fit for what is needed, but also the
   most complex solution. This is a fairly big problem space and I personally
   do not want to pursue this outside a certain narrow scope.

In particular I have serious doubts about retrofitting (at this point in
time) an invasive module system that involves explicit export and import
management, along the lines of what Michal is describing. (Though I will be
happily surprised if someone comes forward with a proposal to do this in a
non-invasive way.)

What I think might be worth pursuing though, is a much weaker package
notion that essentially grants some language-integration to the existing
notion of composer packages. Instead of having a declare_directory() we'd
have declare_package(), which is bound to a certain path and can be used to
specify declares, but also used for other purposes, such as package-private
visibility.

If I may make another Rust analogy, this would be more like Rust crates
than Rust modules. The analogy being that this is a more coarse grained
level, and is fairly tightly integrated with the package manager (but of
course still usable without it).

Regards,
Nikita

On Tue, Jul 30, 2019 at 12:14 PM Michał Brzuchalski michal@brzuchalski.com
wrote:

Hi Rowan,

wt., 30 lip 2019 o 10:48 Rowan Collins rowan.collins@gmail.com
napisał(a):

I think there's some confusion here, because establishing the concept of
a
package as separate from a namespace is exactly what I proposed.

Here's a previous message (technically in the same thread, but from 18
months ago) where I also mentioned class visibility:
https://externals.io/message/101323#101390

Was thinking about similar, a package with own identity and a way to
declare autoload and other stuff.
Was even thinking it could use a double colon which I've proposed way back
in the same thread and
with a delimiter in name all related symbols could be stored in package
individual symbol tables,
it won't collide with namespaced and global ones and would be easier to
detect if tried to use an internal symbol
in another context like other package or in global code.
It could introduce a few more keywords like:

• "package" - for declaring package name and declares,
• "export" - for explicit declare of publicly available symbols which then
  could be detectable etc. for visibility features,
• "expect" - for explicit declare of required dependencies

Last two are for future features and the first one could be enough for
shaping how it could look like.
For eg. some of my thoughts
https://gist.github.com/brzuchal/c45010f0dd20642b470eeee8b9c56c5f

I know it's out of the main topic but IMO we should start another one and
I'm pretty sure I've mentioned that earlier.
If we wanna shape package for PHP then the separate discussion could be a
good idea.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

5. Introduce a first-class module/package concept and support per-package
   declares. This is arguably the closest fit for what is needed, but also the
   most complex solution. This is a fairly big problem space and I personally
   do not want to pursue this outside a certain narrow scope.

In particular I have serious doubts about retrofitting (at this point in
time) an invasive module system that involves explicit export and import
management, along the lines of what Michal is describing. (Though I will be
happily surprised if someone comes forward with a proposal to do this in a
non-invasive way.)

What I think might be worth pursuing though, is a much weaker package
notion that essentially grants some language-integration to the existing
notion of composer packages. Instead of having a declare_directory() we'd
have declare_package(), which is bound to a certain path and can be used to
specify declares, but also used for other purposes, such as package-private
visibility.

If I may make another Rust analogy, this would be more like Rust crates
than Rust modules. The analogy being that this is a more coarse grained
level, and is fairly tightly integrated with the package manager (but of
course still usable without it).

Yes, I was thinking of something more like Composer packages, rather than
like JS modules: code would mostly work as presently, but with some notion
of being "owned" by a particular package. This doesn't mean all the
functions of Composer would be integrated, but could provide richer
primitives, such as registering an autoload callback or preload list to a
particular package, rather than having to perform string matches.

Regards,

Rowan Collins
[IMSoP]

Yes, I was thinking of something more like Composer packages, rather than
like JS modules: code would mostly work as presently, but with some notion
of being "owned" by a particular package. This doesn't mean all the
functions of Composer would be integrated, but could provide richer
primitives, such as registering an autoload callback or preload list to a
particular package, rather than having to perform string matches.

A slight tangent:

At the point we're talking about composer integrating callbacks,
preloading lists etc, isn't it about time that an spl_autoload_list was
added that accepted the standard composer classmap [class_id => path]
and forewent most autoload callbacks entirely?

Mark Randall

At the point we're talking about composer integrating callbacks,
preloading lists etc, isn't it about time that an spl_autoload_list was
added that accepted the standard composer classmap [class_id => path]
and forewent most autoload callbacks entirely?

To be honest, at this point autoloading is barely necessary: just ensure
OpCache is configured correctly and preload all the files. When I tested an
exhaustive class map with OpCache disabled, it was actually slightly slower
than a "non-optimized" autoloader, presumably because the array definition
itself takes so long to compile.

Regards,

Rowan Collins
[IMSoP]

Hi!

If we want to evolve the language without breaking backwards compatibility,
we need to provide a way for gradual migration of the ecosystem: A library
should be able to opt-in to breaking changes, while remaining usable by
downstream consumers. Conversely, an application should be able to opt-in
to breaking changes, while still being able to use an older library.

This assumes breaking changes are necessary for evolution. I am not sure
this is actually true. Java is 21 years old, and I think the code I
first wrote when I learned Java in late 90s would still compile today
(even though nobody would probably want to run it :).
Javascript is 23 years old, and the only thing I can think of that may
break BC is "use strict", which is also local and just one option.
C++ had a myriad of changes lately, and is 34 years old, but I am pretty
sure code written a decade ago - discounting library changes, etc. -
would still compile today.
I think the assumption that we must break old code to be able to
evolve is not correct. Surely, certain directions of evolution - like
converting PHP to strictly-typed language - would require that, but
that's not the only direction possible.

3. Support per-directory declares, which is the direction I was planning to
   explore next. This is based on the premise that all library files are part
   of some top-level directory, which I think is a fairly safe premise (note
   that the "directory" could also be a phar file).

The actual intended use (similar to the namespace-based variant) is that
people will specify their declares in the composer.json file, and composer
then includes a call to declare_directory() or similar as part of the
autoloader. Projects not using composer have the choice of issuing an
explicit call.

Note this also means that syntax and semantics for each file is
runtime-defined and can change any time. With obvious implications for
preloading and opcode caching. Moreover, there could be a situation
where some code includes a file with one set of options, and then
declare_directory() happens that changes the options and another code
includes the same code assuming different set of options. I have no idea
what is supposed to happen in this situation. Since declare_directory()
is non-local, I see no way to ensure that require for certain file
always happens with the same set of options. Of course, one can say
"composer and autoloading will ensure that" - but composer and its
autoloading, while undoubtedly popular, are libraries external to PHP,
and there's a lot of PHP code that is either not using composer, or
using composer in combination with other ways of autoloading. Unless we
mandate use of composer for every PHP project, this still does not solve
the issue.
And, of course, IDEs/analyzers would somehow have to figure this out too

• since composer.json is not actually defining the options (it is only
  an input for declare_directory call sometime later) they'd probably have
  to parse code and find declare_directory() calls? Or they'd just assume
  everything in composer.json? What if I just manually call
  declare_directory() then - would it break everything?

4. Specify declares in a special file, similar to how INI directives are
   declared. The suggestion here has been that PHP could scan the path of an
   included file upwards to find a declares.json (or similar).

This one at least ensures options for certain file are consistent, but
at the cost of introducing magic config files that PHP never had before,
and all complications coming with handling, caching and managing those
files (if declares.json changed, do you have to invalidate all opcode
caches for all files under this directory?).

5. Introduce a first-class module/package concept and support per-package
   declares. This is arguably the closest fit for what is needed, but also the
   most complex solution. This is a fairly big problem space and I personally
   do not want to pursue this outside a certain narrow scope.

That actually would be a workable solution if package semantics were
built into the language. That would ensure same code is always
associated with same options, allow compile-time handling of options and
would let IDEs, analyzers, etc. to have a consistent picture without
trying to parse runtime code. If I had to choose among the options here,
so far it's my favorite one, even though I recognize it may not be easy.

--
Stas Malyshev
smalyshev@gmail.com

Did you actually try to read my argument, of just
decided to strawman it from the start?

I strongly doubt that there is anything that people could say that
would alleviate your concern.

I could say how nicely my IDE gives me a warning when I edit files
from a library that don't belong to the project.

I could point to how the Javascript community are deliberately going
out of their way to make it easier to 'fracture' the language, by
using pre-compilers, and they have used that to drive evolution in the
JS ecosystem.*

But from previous RFC discussions, you only want to discuss possible
concerns; not in an attempt to try to make the RFC better, or to come
up with a better idea, but to just put pressure onto the RFC author to
withdraw the RFC.

The suggestion that RFC authors need to win you over in a discussion,
otherwise they aren't doing their job properly appears to be another
level of trying to shout down RFCs by making life less pleasant for
those RFC authors.

While it's admirable that you are strong in your beliefs, it is
incredibly tiring engaging in RFC discussions with you, when so often
don't it seems to be a waste of time, due to there being nothing that
could be said that would change your mind.

You can't expect people to respond to all of your points, when it
doesn't seem to be a useful use of their time.

cheers
Dan
Ack

• And that the PHP community will have an easier time than JS devs do,
  as PHP devs are completely in control of the computer where their code
  will run, but JS devs have to run their code in a browser which they
  have no control over.

Hi!

I strongly doubt that there is anything that people could say that
would alleviate your concern.

There's a lot of things people could say - for example, a proposal that
does not have the same flaws. If you are fixed on having this proposal
unmodified, then yes, my concerns are not addressed, but I am surprised
that this is somehow presented as my fault, as if I am being
unreasonable voicing my concern about a proposal because these concerns
can not be dismissed with mere rhetoric. I would expect that if that is
the case, the proposal would have to be improved - but seems like
somehow the conclusion being made is that I am unreasonable and the
proposal is just fine.

I could say how nicely my IDE gives me a warning when I edit files
from a library that don't belong to the project.

Not sure how this relates to anything, sorry.

I could point to how the Javascript community are deliberately going
out of their way to make it easier to 'fracture' the language, by
using pre-compilers, and they have used that to drive evolution in the
JS ecosystem.*

As I pointed out in my other emails, I don't remember any Javascript
change that makes the engine reject code written for any of the past 20+
years of Javascript existence. So I am not sure how you see it as a
point in your favor. You're not arguing for making pre-compiler for PHP
(if you want to make one, I am the last person to argue against - full
steam ahead!), you are arguing for making deep changes to the fabric of
PHP itself. This is way different.

But from previous RFC discussions, you only want to discuss possible
concerns; not in an attempt to try to make the RFC better, or to come
up with a better idea, but to just put pressure onto the RFC author to
withdraw the RFC.

That is trying to make RFC better - by evaluating concerns and trying
to resolve them - or concluding they can not be resolved. I am not
pressuring anybody into anything, that is plain false. I am stating
where the proposal is lacking. Of course there are many areas where it
is not - it would be stupid to write a long email outlining where I
agree with RFC author, what use would that be?

You seem to be under the impression that if I see a fault in the
proposal, it is on me to produce a perfect proposal to does exactly the
same (even if I am not yet convinced it should be done at all), and RFC
author owes no effort to anyone to try and address the concerns - either
I or anybody who raises the concerns do it for him and fix his RFC, or
we are unreasonable negative jerks that just want to shut down
everything, and should keep quiet about any problems we see until we
find a solution that does the same but perfectly.

I don't think this is how RFC process should work. I think raising
concerns and expecting the proposal author to address them is absolutely
normal - moreover, vital - part of the process. If the author needs any
help in that, they should ask for it - if it's possible (in some cases
the result could be "this proposal doesn't work" and this is normal too,
I proposed tons of things that didn't work out).

The suggestion that RFC authors need to win you over in a discussion,
otherwise they aren't doing their job properly appears to be another
level of trying to shout down RFCs by making life less pleasant for
those RFC authors.

Not me personally, of course, but most of the people with serious
technical concerns, yes. That I think is what RFC is about. Did you
expect the process to be "Somebody writes RFC, everybody shower them in
praise and adoration, no concerns are raised, the code is committed and
everybody goes to party happily"? That can happen, but with complex
things like completely overhauling 20+-year-old language on a syntax
level, it is unrealistic to expect that. For some RFCs, the decision is
clear and unanimous, I personally votes "yes" on countless number of
them, but sometimes it is more complex than that. If that makes author's
life intolerably unpleasant, I am sorry to hear that but this is not the
reason to give up on proper process because somebody feels they don't
have it in them to support their point of view.

While it's admirable that you are strong in your beliefs, it is
incredibly tiring engaging in RFC discussions with you, when so often
don't it seems to be a waste of time, due to there being nothing that
could be said that would change your mind.

This is obviously false, I've changed my mind many times. You just try
to paint me as unreasonable jerk to save time on generating actual
argument in defense of your position on technical merits - while I do
spend this time and lay out technical arguments. Prudent strategy for
you personally, but disastrous to the quality of the community
discussion. Please let's move discussion for my personal faults as a
human being to technical matters on PHP.

--
Stas Malyshev
smalyshev@gmail.com

Thanks everyone for your responses!

I think the discussion resolves around two primary concerns, so let me
address them in turn.

The first is the general approach of using declares as a
language-evolution mechanism. The concern here is that each additional
declare fragments the language and increases the number of combinations of
different options there are.

What I ultimately want to achieve here is a way to evolve the language and
fix long-standing issues without breaking backwards compatibility or
causing ecosystem fragmentation. The only way we currently have to address
(nowadays) undesirable behavior is through deprecation and subsequent
removal. As people like to regularly remind me, this has a high cost on the
ecosystem, because millions of codebases that were running without a glitch
need to be updated, which not only takes a lot of effort, but also delays
adoption of new PHP versions for everyone. As such, the "deprecation and
removal" approach has to work over long time-frames and is only really
applicable to rather "minor" issues in the first place.

If we want to evolve the language without breaking backwards
compatibility, we need to provide a way for gradual migration of the
ecosystem: A library should be able to opt-in to breaking changes, while
remaining usable by downstream consumers. Conversely, an application should
be able to opt-in to breaking changes, while still being able to use an
older library.

To achieve this, I believe it is unavoidable to have some kind of
mechanism to affect language-behavior on a per-library/project level. Of
course, the devil tends to be in the details...

What this RFC originally proposed is a fine-grained approach, where
individual changes are controlled by separate declare directives. However,
this is not the only possibility: As has been recently popularized with
Rust editions (https://doc.rust-lang.org/edition-guide/editions/index.html),
a coarse-grained approach where multiple changes have to be enabled
together as part of an "edition" is also possible.

The advantage of the coarse-grained "edition" approach is that it avoids a
combinatorial explosion of options: It's all or nothing, and it is easier
to keep in mind that a project uses "PHP 2020" rather than some specific
combination of declares.

The advantage of a fine-grained approach is that is also allows a
fine-grained migration. As a statically-typed language, Rust can provide
fairly reliable tooling to perform edition migrations. While such tooling
also exists for PHP (e.g. Rector), it does not have the same level of
reliability, especially for codebases that do not make pervasive use of
type annotations. Fine-grained declares allow a code-base to be updated one
step at a time.

It is possible to combine both approaches by providing both fine-grained
control and an overall "edition" that enables a larger set of language
declares. The end goal should be to move to the next edition, but
individual declares may be used during the migration, or to opt-out a
section of code. This is probably my preferred approach.

I should probably also highlight that this is somewhat different from the
existing strict_types directive: strict_types was only in part a mechanism
to control BC breakage (with regard to internal functions), but to a large
part exists because we couldn't agree on which semantics are preferable.

This is not what I'm going for here. I don't want declares to becomes a
way to resolve disagreements by just providing both options. Instead a
declare represents a change that we want to make and that codebases
should make eventually, but that is opt-in to maintain backwards
compatibility and library interoperability.

---

The second concern is around the technical details of opting-in to
BC-breaking language changes on the library level. Here is an overview of
some proposals that have been made:

1. Keep declares per-file. This is clearly incompatible with any
   fine-grained (or optionally fine-grained) approach, because declares have
   to be replicated across hundreds of files. I think this is a bad choice
   also for a coarse-grained approach (or even for the existing strict_types
   directive), because in all cases I've seen people want to enable the option
   for the whole library, not individual files.

Replicating declares per-file is error prone (I regularly forget to add
strict_types declarations to newly created files) and complicates the
mental model of the programmer. While ostensibly per-file declares make
things explicit, I think the reality is that nobody actually double-checks
declares in each file they open and will instead assume that the project
default holds.

2. Support per-namespace declares. This is what I originally proposed.
   This is based on the premise that a library will usually correspond to a
   namespace. This approach has been extensively discussed in this thread -- I
   think the main issue is that the premise just doesn't reliably hold up in
   practice, e.g. because multiple packages publish under the same namespace.

3. Support per-directory declares, which is the direction I was planning
   to explore next. This is based on the premise that all library files are
   part of some top-level directory, which I think is a fairly safe premise
   (note that the "directory" could also be a phar file).

The actual intended use (similar to the namespace-based variant) is that
people will specify their declares in the composer.json file, and composer
then includes a call to declare_directory() or similar as part of the
autoloader. Projects not using composer have the choice of issuing an
explicit call.

After looking into the implementation side a bit, I think I remember why I
didn't go down this route originally: Path canonicalization is tricky.

Namespaces have the big advantage that they are fully controlled by PHP,
with well-defined semantics. Plain filesystem paths have a well-defined
realpath canonicalization, but things are less simple for general streams.

The engine already needs to solve this problem for the purpose of
include_once and require_once and provides the zend_resolve_path hook for
this. However, it doesn't really support stream wrappers (phar has some
support here, but the last time I looked into it I didn't get the
impression that it's reliable). There's the additional question of caching:
In an opcache'd scenario we wouldn't want to have any stat traffic. Opcache
does perform caching of resolved paths, but I think this currently only
extends to actually cached files, while we'd also need directories in this
case.

These problems can probably be overcome, possibly by making path resolution
a first-class stream wrapper function, but it does make things a good bit
more complicated relative to the namespace-based approach, and possibly
also more fragile.

I'm somewhat stumped at this point. The most reliable approach (and in a
certain way also technically simplest) would be to have a package
declaration in every file, as suggested by Michal ... but of course this
does require adding the package declaration everywhere and complicates
migration.

Nikita

4. Specify declares in a special file, similar to how INI directives are

declared. The suggestion here has been that PHP could scan the path of an
included file upwards to find a declares.json (or similar).

The main advantage I see here (over a declare_directory() function) is
that there are no loading order issues. declare_directory() needs to be
called before any files from that directory have been included (which is
part of why an integration into the composer autoloader is useful), while
for a separate and implicitly processed file this falls out naturally.

Apart from that, I'm not a big fan of this proposal, mostly because of the
implicit loading it entails. I also don't think that having one more
configuration file for this buys us something over declaring things in
composer.json.

5. Introduce a first-class module/package concept and support per-package
   declares. This is arguably the closest fit for what is needed, but also the
   most complex solution. This is a fairly big problem space and I personally
   do not want to pursue this outside a certain narrow scope.

In particular I have serious doubts about retrofitting (at this point in
time) an invasive module system that involves explicit export and import
management, along the lines of what Michal is describing. (Though I will be
happily surprised if someone comes forward with a proposal to do this in a
non-invasive way.)

What I think might be worth pursuing though, is a much weaker package
notion that essentially grants some language-integration to the existing
notion of composer packages. Instead of having a declare_directory() we'd
have declare_package(), which is bound to a certain path and can be used to
specify declares, but also used for other purposes, such as package-private
visibility.

If I may make another Rust analogy, this would be more like Rust crates
than Rust modules. The analogy being that this is a more coarse grained
level, and is fairly tightly integrated with the package manager (but of
course still usable without it).

Regards,
Nikita

On Tue, Jul 30, 2019 at 12:14 PM Michał Brzuchalski <
michal@brzuchalski.com> wrote:

Hi Rowan,

wt., 30 lip 2019 o 10:48 Rowan Collins rowan.collins@gmail.com
napisał(a):

I think there's some confusion here, because establishing the concept
of a
package as separate from a namespace is exactly what I proposed.

Here's a previous message (technically in the same thread, but from 18
months ago) where I also mentioned class visibility:
https://externals.io/message/101323#101390

Was thinking about similar, a package with own identity and a way to
declare autoload and other stuff.
Was even thinking it could use a double colon which I've proposed way back
in the same thread and
with a delimiter in name all related symbols could be stored in package
individual symbol tables,
it won't collide with namespaced and global ones and would be easier to
detect if tried to use an internal symbol
in another context like other package or in global code.
It could introduce a few more keywords like:

• "package" - for declaring package name and declares,
• "export" - for explicit declare of publicly available symbols which then
  could be detectable etc. for visibility features,
• "expect" - for explicit declare of required dependencies

Last two are for future features and the first one could be enough for
shaping how it could look like.
For eg. some of my thoughts
https://gist.github.com/brzuchal/c45010f0dd20642b470eeee8b9c56c5f

I know it's out of the main topic but IMO we should start another one and
I'm pretty sure I've mentioned that earlier.
If we wanna shape package for PHP then the separate discussion could be a
good idea.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

I really like this approach. It allows a package definition file to
exist, without either the language or the header of each file having
to define its location.

File: /lib/company/project1/a/b/MyClass.php

<?php

  declare_import(company[:label]);

  namespace company/project1/a/b;

  ...

File: /lib/company/__nsmeta.php

<?php

  namespace company;

  namespace_declare [:label] {
    strict_types=1;
    strict_operators=1;
    upgrade_errors_to_exceptions=E_ALL;
  }

  final class __nsmeta {
    /* does nothing except be findable by the autoloader /
    / and defaults to private constructor so it can't be used */
  }

This seems to be more complicated than Nicolas's version, and involve
much more special magic, like the name __nsmeta, and the class that does
nothing. I'm also not clear on how you're picturing the relationship
between namespaces and packages.

The way I understood the suggestion, you'd end up with something more
like this, which feels much simpler and cleaner:

File: /lib/company/project1/a/b/MyClass.php

<?php

declare(package=company/project1);
// or with a new keyword
package company/project1;

namespace company/project1/a/b;

...

File: /lib/company/project1.php

<?php

namespace company;

class project1 extends \PHP\Package {
    public function getParserDirectives() {
        return [
            'strict_types' => 1,
            'strict_operators' => 1,
            'upgrade_errors_to_exceptions' => E_ALL
        ];
     }
}

Regards,

--
Rowan Collins
[IMSoP]

I thought about this as my first consideration, however it effectively
requires that the PHP code within the package class is fully parsed
and executed in order for it to retrieve the data.

Consider pre-loading where the code is compiled, but not run, it would
not be possible to use namespace level defines to add compile-level
optimizations or checks (at least without some AST hackery).

Ah, that makes sense. Does that necessarily mean we need a dummy class,
though? The autoloading logic in the engine knows that it called the
autoload callback expecting a package definition, so can count as
success that the package is now defined.

In other words, the file the autoloader included would look like this
(again, sticking to the notion that "package" is separate from "namespace"):

File: /lib/company/project1.php

<?php

packagedef company/project1 {
    strict_types=1;
    strict_operators=1;
    upgrade_errors_to_exceptions=E_ALL;
}

Regards,

--
Rowan Collins
[IMSoP]

<?php

declare(strict_types=1) {
class Example {
// ...
}
}

This already works (except for the "encoding" declare, which would make
little sense halfway down a file).

spl_autoload_register(function ($className) {
declare(strict_types=1) {
include $className . '.php';
}
});

This, however, doesn't, because each file has to declare its own
options, so we'd need some new syntax for "include with current parser
options". It would also lead to the possibility for the same file to be
included twice with different options, which would be confusing; or for
it to be in OpCache twice with different options, which would be complex
to implement.

Regards,

--
Rowan Collins
[IMSoP]

Ah, that makes sense. Does that necessarily mean we need a dummy
class, though? The autoloading logic in the engine knows that it
called the autoload callback expecting a package definition, so can
count as success that the package is now defined.

In other words, the file the autoloader included would look like this
(again, sticking to the notion that "package" is separate from
"namespace"):

Personally with file-level opt ins I'm not 100% sold on the benefits
of packages over namespace level information. I guess I'm not certain
on what problem they're trying to solve that's different from just
another object at namespace level.

The problem they're trying to solve is that at the moment, there is no
namespace-level information. Namespaces form an arbitrarily deep
hierarchy, and don't need to be declared before they're used; it's hard
to retrofit configuration into that. In my mind a package would be very
similar to a namespace, but would have a mandatory declaration
somewhere, giving a place to define its settings and properties; and
there would be no "sub-packages", so no need to define inheritance and
over-rides.

As for the dummy class, the only real benefit is that existing
autoloading procedures can be used to locate it and be included with
minimal overhead.

PHP can call the autoloader internally but it would require userland
loaders to be upgraded with it, not exactly a huge stretch, especially
with most things being composer-based, but a dummy class would make it
work out the box, including optimization steps like dumping the class
list.

I see what you mean; but the change needed to autoloaders would be
pretty minimal: if they just turn the name into a file path and run
file_exists(), no change at all; if they tokenize files in advance to
build a class map, they would need to add "packagedef" to the list of
tokens to search for, alongside "class", "interface", and "trait". The
same change would be needed if we introduced a "struct" or "enum"
keyword, and I don't think anyone would expect to write dummy classes
alongside those.

Regards,

--
Rowan Collins
[IMSoP]