Fair, and I have heard this from both Ben and Alex earlier in the thread.
My pushback there has been that the engine already has the filename
available at zend_compile_file and at include/require resolution, so
teaching it to check the extension is additive rather than architecturally
violating. But I take the point that this is a cultural preference on the
list, not just a technical one. If there is a workable alternative that
does not have the caller-vs-author inversion problem I raised in my reply
to Alex, I am open to it.
I can't think of one to be honest. The parser needs to know how to handle
the file. That's going to come in the form of the extension or in the
calling statement from within PHP. Any extension choice comes with the
potential BC break that someone, somewhere out there has used that
extension before.
- I would caution against any code only include being implemented
without taking the opportunity to fix certain bugs that have gotten
to stick around because of the enormous BC breaks such fixes
introduce. There are no existing files in this format, therefore no
existing code to have a BC break. This is a rare opportunity to
clean some things that should not be passed on. Please, Please look
into this as part of this.This is the most important point you raised and I want to be careful with
it. You are right that introducing a new file format is a once-in-a-decade
opportunity to ship semantics that would otherwise be blocked by BC. Your
Modules proposals have been built around exactly this argument, Hack took
the same route, and the temptation to bundle improvements is real and
well-founded.My reservation is purely tactical: every additional semantic change is an
additional reason a voter might decline. An RFC scoped to "new file format
that starts in scripting state" is already non-trivial to defend. An RFC
scoped to "new file format with stricter type juggling, no eval, no
variable variables, automatic strict_types, no @ suppression" is a
substantially harder sell, and the list has a history of preferring focused
RFCs over Christmas trees. I want to avoid the derailment pattern.I think the right approach is to surface this in the RFC text as an
explicit Open Question: "Should pure-code files differ from .php files in
semantics beyond the entry parsing state, and if so, in which specific
ways?" Rather than committing to a list now, I would let the list propose
specific cleanups and only include those that have clear consensus.Given your years of iteration on this concept, you almost certainly have a
more grounded list of candidate cleanups than I do. Would you be willing to
share which specific bugs or semantic issues you had in mind? Some that
come to my own mind: automatic declare(strict_types=1), banning variable
variables, banning @ error suppression, banning the global keyword. But I
would value your concrete examples more than my abstract candidates.
Those would be a good start. I don't know of any others offhand because I
don't know the engine. I'd have to dig around in the rfc archives to find
other examples.
There's a bit of a quandary here - just removing the need for the <?php ?>
markup doesn't come with enough upside to be justified on its own in my
opinion. It might be doable with the requirement that if a php file doesn't
start with <?php it must instead start with the namespace declaration, but
is this worth the potential confusion.
This honestly would need to be part of a larger syntax cleanup effort for
the benefit of both the engine and the users. The largest single wart in
PHP syntax is the having three scope operators ( , ->, :: ) where its
sister languages get by with only one ( . ) which PHP uses for a different
operation. But I believe that runs into similar problems as the reason why
PHP requires $ to lead all variables, it has to do with how the engine
handles these symbols. I suspect that some of these problems are
intractable and even if they can be solved the performance hit in solving
them might be severe. If that isn't the case (or isn't the case anymore)
then those structures too would be worth review.
This rounds back to a weakness of the RFC process - it works best for small
to medium scope changes. Decisions on large architectural paths are more
difficult (but not impossible).
I got quiet on modules because I don't have the skill to follow it through,
or the time to develop those skills. I was working with Rowain on a
possible path last year, but got distracted by work and dropped the ball.
The problem scope for that, though closely tied to this, is uncomfortably
large.