On Thu, Jun 27, 2024 at 2:41 PM Jim Winstead <j...@trainedmonkey.com> wrote:
> On Thu, Jun 27, 2024, at 2:14 PM, Jordan LeDoux wrote: > > On Thu, Jun 27, 2024 at 12:53 PM Jim Winstead <j...@trainedmonkey.com> > wrote: > > > On Wed, Jun 26, 2024, at 7:15 PM, Michael Morris wrote: > > PHP User Modules are php files that are brought into the runtime through a > new parser that is able to generate faster and more concise runtime code by > removing support for problematic features and imposing a strict mode by > default. They focus on PHP as a language and not as a template engine. > > > I think the problem I have with this proposal is calling these "PHP User > Modules". Here's an admittedly uncharitable rephrase of this: > > "NewLanguage User Modules are NewLanguage files that are brought into the > PHP runtime through a new parser that may theoretically be able to generate > faster and more concise runtime code by implementing a different language > based on much of the syntax from PHP. This new language does not prioritize > its use as a template language for HTML." > > > Do you feel that Phar is a separate language? Is PHP no longer PHP if the > @ error suppression is removed? I'm really unclear about the point you are > making here, even if I ignore the "uncharitable" rephrase. > > > If I read through the 11 bullet points under "User Module Files" in the > original proposal, I see two that are actually related to modules and most > of them are just lopping off features from the PHP language in ways both > small (no need for <?php) and huge (changing the scoping operator to '.' > instead of '::', '->', and '\'). > > The angle I am coming at this from is improving the developer experience > around "packages" or "modules" or whatever you want to call them, and so > much of this proposal doesn't seem to be about that. > > I could have made that point in other ways, and I'm sorry that my first > attempt came off as insulting. It really concerned me when I already saw > discussion about taking this off-list and going into the weeds on technical > details when the problem that is being addressed by this proposal is > extremely unclear to me. > > Jim > Ah, yes, THAT'S a fair point. While the idea of optimizing the engine/parser for modules has merit as part of a user modules proposal, I agree that many of the specifics proposed here feel pretty scatter-shot and unclear. The scoping operator change I simply ignored, as that feels to me like just asking "I would like to program in Node" and there's no clear benefit to changing the scoping operator outlined, while there is a clear detriment to eliminating the concatenation operator entirely. Mostly I ignored that aspect of it, because I assumed that all the people capable of implementing this proposal would just refuse stuff like that outright, and that the inclusion of it would guarantee the RFC fails, so no point in worrying. But the broader question you are presenting about the focus and goals of the proposal, and how the specifics relate to that, is actually a question that I share. Jordan
