On Tue, Apr 11, 2023, at 1:40 AM, Michael Morris wrote:
> This will be long. I've read over the Future Stability thread and taken it
> in, and decided to mull over an idea I touched on over a decade ago that I
> think might help. Also, in the interceding years the JavaScript community
> has overcome a compatibility issue using this technique, so we might do the
> same.
>
> The crux of the stability problem is the need to update functions without
> introducing a BC break. Adding in new features without removing old ones
> also makes it confusing to incoming programmers as to what to use.
>
> I propose PHP Modules to hold new features. The existing namespace and
> functions would be left alone. Existing files would also not be affected -
> the behavior of PHP modules would be entirely opt in.
>
> They would work similar JavaScript modules - they would use the import
> keyword and the include, require, include_once and require_once directives
> would pitch an error if used in a PHP module. PHP Modules also would not
> parse as templates at all - no opening <?php tag needed (and yes, I know
> that will be a headache for IDE makers, but it's not insurmountable).
>
> PHP would have a new ini directive to use them similar to the "type":
> "module" directive that npm uses now. If that ini directive isn't set, php
> files would be handled as they always have. mphp files would always be
> handled as php modules though and lphp (legacy php) would always be handled
> as legacy php.
>
> I expect some objection to file extensions affecting parsing behavior, but
> over the last 5 years this approach has worked for the JavaScript community
> with cjs, mjs and js files. Here the existing php, phtml, php3, php4
> extensions are handled as the directive instructs them to be handled, only
> the two new never before used extensions of lphp and mphp would do their
> thing.
>
> In a PHP module a function has to be imported before it's used with a
> handful of exceptions. The root namespace of php modules is utterly empty,
> or as close to empty as makes sense.
>
> The existing functions would be gathered into modules so that they can be
> imported. While this is done the headache inducing inconsistencies like
> haystack, needle for strings and needle, haystack for arrays can be
> addressed. I really don't care which is adopted, but having one order for
> this language wide would be nice. Also, decide once and for all - camelCase
> or underscore_case.
>
> The above alone would be massive. Maybe it's impossible given the number
> of devs available. The one thing modules can do that the current system
> cannot is allow devs to pick which version of the module to use:
>
> import split from 'php.mb' // imports the mbsplit() function from the
> current version of PHP.
>
> Say the mb module gets some bc breaks. We can put them into a new module so
> that the behavior is once again opt in. The strongest way to do this is to
> make composer a 1st class part of the language and let it specify the
> version of the module that is loaded.
>
> The import command would be able to pull from the file system or from the
> import map as JavaScript does currently. For ease of dev headaches I'd
> recommend hewing to the JS model as close as possible as it is proven, and
> many of us already use it anyway when developing browser code.
>
> I hope this helps, or at least spurs a conversation to come up with
> something to address this issue.
The main question, in my mind, is what problem is this solving. From the description here, it sounds like you're targeting "clean up inconsistencies in the stdlib", which could be done much more easily by putting new versions in a namespace, something that's been discussed many times. (And usually run into a wall of how much redesigning we should do in the process, and then people lose interest.)
The previous times modules have been proposed, the big selling point was module-level visibility. Eg, object properties or methods that are visible to other classes/functions in the same module, but not outside of it. That's a problem space that would be solved by modules, which namespaces cannot solve. (Whether worth the effort or not is a separate question.)
Most of the BC discussion right now (and generally) isn't about function or class redesign. It's about changes in language syntax behavior, such as undefined-var/key being promoted from Notice to Warning (8.0), or making dynamic properties opt-in via an attribute, or having stdlib functions react to null parameters the same way as userspace functions, etc. Regardless of whether you consider those good or bad changes, they're not the sort of thing that modules would solve.
There has been discussion in the past of adding more declare statements to allow opt in/out of certain changes, like declare(warn_on_missing_var=1) or something. To whatever extent that's feasible, it's less work than doing it that way (per-file) than introducing a module system to handle that switch. However, as previous discussions have shown that is also a huge amount of work, as we have to maintain two different behaviors in the engine and switch per file... and then also figure out when the default changes, and when it becomes just the new approach always. Which doesn't solve the issue that at some point code that ignores missing variables *will still break*, it's just pushing that date off even longer at the cost of still more engine complexity. But the same people will still complain just as loudly whenever that is, because they haven't done anything about it for the past 17 years so they're not going to now.
So, what are the problems to be solved that only a good module system would be able to? Start there, before thinking about how a module system would look. I do think there are potential benefits to a formal module/package system, but that's where the discussion would need to start, not with what the <? tag looks like.
--Larry Garfield
