Hi! On Sun, May 4, 2025 at 8:08 AM Arvids Godjuks <arvids.godj...@gmail.com> wrote:
> > > On Sun, 4 May 2025 at 10:36, Michael Morris <tendo...@gmail.com> wrote: > >> It's been 9 months. Been researching, working on other projects, mulling >> over >> points raised the last time I brought this up. And at the moment I don't >> think >> PHP 8.5 is in its final weeks so this isn't a distraction for that. The >> previous discussion got seriously, seriously derailed and I got lost even >> though >> I started it. I'm not going to ask anyone to dig into the archives, let's >> just >> start afresh. >> >> *snip* >> > > I've started reading, saw Wordpress... almost stopped right there, but > decided *okay, this is too rash of me, read further*.... > > "My disappointment is immeasurable and my day is ruined".gif > It ended exactly how my first judging brain wave thought it would go - > this whole thing is about fixing WordPress by changing the language. Plain > and simple. > > No. > I think that is a very short sighted statement about the proposal. I have been using PHP for 15 years and I don't know, don't use nor don't care about the Wordpress ecosystem. However, the proposal has immeasurable merits to address many things that have been discussed several times on this list over the years. 1- Private classes. Instead of the currently being discussed nested class declaration with its own set of awkwardness, Modules would allow the declaration of classes that are not globally visible. Regardless of the state of Wordpress, **at first glance** this seems a superior proposal than Nested Class. 2- Friends classes. It has been discussed a couple of times the introduction of class friendship as a way to expose internals of a class only to a specific subset of known / expected classes. This has some foundation in the fact that you don't want to declare public attributes in a global class. With modules, you could declare a class that is not exported to the global scope and use public attributes knowing full well that only classes within your own module will be able to touch them. Again, major props to this proposal over Friends classes. 3- Class autoload vs Function autoload. There have been hundreds of hours spent on discussing function autoloading. I don't quite remember why that is such a hot topic and I also don't remember what it tries to accomplish, but it seems adjacent enough to consider that maybe this proposal could be a door on that realm as well. 4- Familiarity with the Typescript ecosystem. For better or worse, browsers run on Javascript for 3 decades and not even Wasm is fully changing that. This proposal is too familiar from Typescript's import / export system and would help bridge the gap for frontend engineers to better understand the flow of PHP code. ----------- I haven't read (or don't remember) the old discussion. From a superficial look of the proposal, it does seem rather awkward to not go full in with `import / export` keywords, even if it requires a soft reserved keyword. I'm not sure the syntax would require a full hard keyword reservation? Perhaps yield is good enough instead of export, but `use require` does seem rather odd. import ... require (as opposed to import ... from) would also work better-ish. In any case, this threads in bikeshedding space. I guess I'd rather have use .... require anyway than not have it at all, specially since IDEs often end up writing it for us anyway. -- Marco Deleu
