Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123988
Content-Type: multipart/alternative;
 boundary="------------lf1hyf0ZzTy35xa6VO96OCrl"
Message-ID: <1843d9ca-ac3d-408a-b018-9181ed03a6c5@seld.be>
Date: Fri, 28 Jun 2024 16:05:25 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
To: internals@lists.php.net
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <1f556e18-cefb-4a15-b96b-08118e48610c@app.fastmail.com>
Content-Language: fr
In-Reply-To: <1f556e18-cefb-4a15-b96b-08118e48610c@app.fastmail.com>
From: j.boggiano@seld.be (Jordi Boggiano)

This is a multi-part message in MIME format.
--------------lf1hyf0ZzTy35xa6VO96OCrl
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

First of all a quick note for the OP: I am all for it in general, but I 
don't think copying the entire JS module system one to one makes sense. 
It contains a lot of compromises and mistakes that we should absolutely 
learn from as well as the good things they did.

On 2024-06-28 00:41, Larry Garfield wrote:

> Which of these are we trying to solve? (Solving all of them at once is 
> unlikely, and some are mutually-incompatible.)
> 1. Adding a "strict pedantic mode" without messing with existing code?
> 2. Package-level visibility (public, package, protected, private)?
> 3. Avoid name clashes?
> 4. Improved information for autoloaders and preloading, possibly making class-per-file unnecessary in many cases?
> 5. A larger scope for the compiler to analyze in order to make optimizations?
> 6. Package-level declares, inherited by all files in the package?
> 7. Something else?

I agree with most of your analysis, and IMO Package-level visibility is 
the main direct win, with a larger scope for JIT optimization coming later.

It would however be very tempting to bake in 1, and remove a bunch of 
things which are not removable from the language at large due to BC, as 
that might be a once in a lifetime opportunity. Some features make JIT 
optimizations nearly impossible (Nikita had a list somewhere.. but the 
main one if probably killing references).

The autoloader information to be honest I am not sure how important this 
is. For everyone not wanting to do class-per-file, note that you can 
just use "classmap" autoloading in Composer. It is anyway the most 
performant option at runtime [1]. The only catch is you have to re-dump 
the autoloader when adding new classes/files to make them discoverable. 
But I think everyone's kinda too stuck on PSR-4 because it is a standard.

> Do we want:
>
> 1. Packages and namespaces are synonymous?  (This is roughly how JVM languages work, I believe.)
> 2. Packages and files are synonymous?  (This is how Python and Javascript work.)
> 3. All packages correspond to a namespace, but not all namespaces are a package?
>
> And given the near-universality of PSR-4 file structure, what impact would each of those have in practice?  (Even if packages open up some new autoloading options and FIG publishes a new PSR for how to use them, there's only a billion or so PSR-4 class files in the wild that aren't going away any time soon.)  My gut feeling is we want 3, but I'm sure there's a debate to be had there.

I'd go for 3 as well. Every package having a single root namespace is 
probably true of 99% of packages due to the PSR-4 autoload root. 
Sub-namespaces are discretionary.

[1] https://getcomposer.org/doc/articles/autoloader-optimization.md

-- 
Jordi Boggiano
@seldaek -https://seld.be

--------------lf1hyf0ZzTy35xa6VO96OCrl
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>First of all a quick note for the OP: I am all for it in general,
      but I don't think copying the entire JS module system one to one
      makes sense. It contains a lot of compromises and mistakes that we
      should absolutely learn from as well as the good things they did.<br>
    </p>
    <p>On 2024-06-28 00:41, Larry Garfield wrote:</p>
    <blockquote type="cite"
      cite="mid:1f556e18-cefb-4a15-b96b-08118e48610c@app.fastmail.com"><span
      style="white-space: pre-wrap">Which of these are we trying to solve?  (Solving all of them at once is unlikely, and some are mutually-incompatible.)</span>
      <pre class="moz-quote-pre" wrap="">
1. Adding a "strict pedantic mode" without messing with existing code?
2. Package-level visibility (public, package, protected, private)?
3. Avoid name clashes?
4. Improved information for autoloaders and preloading, possibly making class-per-file unnecessary in many cases?
5. A larger scope for the compiler to analyze in order to make optimizations?
6. Package-level declares, inherited by all files in the package?
7. Something else?
</pre>
    </blockquote>
    <p>I agree with most of your analysis, and IMO Package-level
      visibility is the main direct win, with a larger scope for JIT
      optimization coming later.</p>
    <p>It would however be very tempting to bake in 1, and remove a
      bunch of things which are not removable from the language at large
      due to BC, as that might be a once in a lifetime opportunity. Some
      features make JIT optimizations nearly impossible (Nikita had a
      list somewhere.. but the main one if probably killing references).</p>
    <p>The autoloader information to be honest I am not sure how
      important this is. For everyone not wanting to do class-per-file,
      note that you can just use "classmap" autoloading in Composer. It
      is anyway the most performant option at runtime [1]. The only
      catch is you have to re-dump the autoloader when adding new
      classes/files to make them discoverable. But I think everyone's
      kinda too stuck on PSR-4 because it is a standard.<span
      style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
      cite="mid:1f556e18-cefb-4a15-b96b-08118e48610c@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">Do we want:

1. Packages and namespaces are synonymous?  (This is roughly how JVM languages work, I believe.)
2. Packages and files are synonymous?  (This is how Python and Javascript work.)
3. All packages correspond to a namespace, but not all namespaces are a package?

And given the near-universality of PSR-4 file structure, what impact would each of those have in practice?  (Even if packages open up some new autoloading options and FIG publishes a new PSR for how to use them, there's only a billion or so PSR-4 class files in the wild that aren't going away any time soon.)  My gut feeling is we want 3, but I'm sure there's a debate to be had there.
</pre>
    </blockquote>
    <p><span style="white-space: pre-wrap">I'd go for 3 as well. Every package having a single root namespace is probably true of 99% of packages due to the PSR-4 autoload root. Sub-namespaces are discretionary.
</span></p>
    <p><span style="white-space: pre-wrap">[1] <a class="moz-txt-link-freetext" href="https://getcomposer.org/doc/articles/autoloader-optimization.md">https://getcomposer.org/doc/articles/autoloader-optimization.md</a>
</span></p>
    <pre class="moz-signature" cols="72">-- 
Jordi Boggiano
@seldaek - <a class="moz-txt-link-freetext" href="https://seld.be">https://seld.be</a></pre>
  </body>
</html>

--------------lf1hyf0ZzTy35xa6VO96OCrl--