Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123975
Feedback-ID: id5114917:Fastmail
Message-ID: <481ee7fb-5a9f-4f36-af19-7615ad38b81f@rwec.co.uk>
Date: Thu, 27 Jun 2024 23:00:30 +0100
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>
Content-Language: en-GB
In-Reply-To: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 27/06/2024 03:15, Michael Morris wrote:
> If you got this far, thank you. This overall idea to take one of the 
> better things to happen to JavaScript in the last decade and 
> incorporate it into PHP has been bothering me for awhile so I figured 
> I'd share.  I don't know how much merit there is to this though.


Thank you for sharing. I think it's valuable to explore radical ideas 
sometimes.

I do think PHP badly needs a native concept of "module" or "package" - 
in fact, I'm increasingly convinced it's the inevitable path we'll end 
up on at some point. BUT I think any such concept needs to be built on 
top of what we have right now. That means:

- It should build on or work in harmony with namespaces, not ignore or 
replace them
- It should be compatible with Composer, but not dependent on it
- It should be easy to take existing code, and convert it to a 
module/package
- It should be easy to carry on using that module/package after it's 
been converted

If we can learn from other languages while we do that, I'm all for it; 
but we have to remember that those languages had a completely different 
set of constraints to work with.

For instance, JS has no concept of "namespaces", but does treat function 
names as dynamically scoped alongside variables. So the module system 
needed to give a way of managing how you imported names from one scope 
to another. That's not something PHP needs, because it treats all names 
as global, and namespaces have proved an extremely successful way of 
sharing code without those names colliding.


Other parts of your e-mail are essentially an unrelated idea, to have 
some new "PHP++" dialect, where a bunch of "bad" things are removed. 
You're not the first person to be tempted by this, but I think the 
history HHVM and Hack is educational here: initially, PHP and Hack were 
designed to interoperate on one run-time, but the more they tried to 
optimise for Hack, the harder it became to support PHP, and now Hack is 
a completely independent language.

I'm not even sure what problem some of your ideas are intended to solve, 
e.g. using "." instead of "::" and "->". At that point, it really does 
feel like you just want to create a new language, mixing ideas from PHP 
and JS, but incompatible with either of them.


I do hope this discussion can inspire some interesting ideas, but I 
don't think what you've presented is the right way to go.


Regards,

-- 
Rowan Tommins
[IMSoP]