Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127281
Precedence: bulk
MIME-Version: 1.0
References: <CAEUnE0c88jp9LeoHnngqvU+XjL_fpwPcfKi1g7hg6k6PBN6KCQ@mail.gmail.com>
 <CAL0xaBEiyRzyTXR0sDE-A9+q7Gj0L=q1SwgcPdt8yJzDS4w4wA@mail.gmail.com>
In-Reply-To: <CAL0xaBEiyRzyTXR0sDE-A9+q7Gj0L=q1SwgcPdt8yJzDS4w4wA@mail.gmail.com>
Date: Sun, 4 May 2025 09:15:05 -0300
Message-ID: <CADK1yXJeASphdwvxekHLY4aKorM+-JWRU4rT7u7J50-Bw_-S8A@mail.gmail.com>
Subject: Re: [PHP-DEV] Modules, again.
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Michael Morris <tendoaki@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000098112206344e5763"
From: deleugyn@gmail.com (Deleu)

--00000000000098112206344e5763
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi!

On Sun, May 4, 2025 at 8:08=E2=80=AFAM Arvids Godjuks <arvids.godjuks@gmail=
.com>
wrote:

>
>
> On Sun, 4 May 2025 at 10:36, Michael Morris <tendoaki@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 eve=
n
>> 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. Plai=
n
> 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.

--=20
Marco Deleu

--00000000000098112206344e5763
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi!</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 4, 2025 at 8:08=
=E2=80=AFAM Arvids Godjuks &lt;<a href=3D"mailto:arvids.godjuks@gmail.com">=
arvids.godjuks@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 4 May=
 2025 at 10:36, Michael Morris &lt;<a href=3D"mailto:tendoaki@gmail.com" ta=
rget=3D"_blank">tendoaki@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>It&#39;s been 9 mon=
ths. Been researching, working on other projects, mulling over <br>points r=
aised the last time I brought this up. And at the moment I don&#39;t think =
<br>PHP 8.5 is in its final weeks so this isn&#39;t a distraction for that.=
=C2=A0 The <br>previous discussion got seriously, seriously derailed and I =
got lost even though <br>I started it. I&#39;m not going to ask anyone to d=
ig into the archives, let&#39;s just <br>start afresh.<br><br>*snip*</div><=
/div>
</blockquote></div><div><br clear=3D"all"></div><div>I&#39;ve started readi=
ng, saw Wordpress... almost stopped right there, but decided *okay, this is=
 too rash of me, read further*....</div><div><br></div><div>&quot;My disapp=
ointment=C2=A0is immeasurable=C2=A0and my day is ruined&quot;.gif</div><div=
>It ended exactly how my first judging brain wave thought it would go - thi=
s whole thing is about fixing WordPress by changing the language. Plain and=
 simple.</div><div><br></div><div>No.</div><div dir=3D"ltr" class=3D"gmail_=
signature"><div dir=3D"ltr"></div></div></div></blockquote><div><br></div><=
div>I think that is a very short sighted statement about the proposal. I ha=
ve been using PHP for 15 years and I don&#39;t know, don&#39;t use nor don&=
#39;t care about the Wordpress ecosystem. However, the proposal has immeasu=
rable merits to address many things that have been discussed several times =
on this list over the years.</div><div><br></div><div>1- Private classes. I=
nstead of the currently being discussed nested class declaration with its o=
wn 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.</div><div><br></=
div><div>2- Friends classes. It has been discussed a couple of times the in=
troduction 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&#39;t want to declare public attributes in a glob=
al class. With modules, you could declare a class that is not exported to t=
he global scope and use public attributes knowing full well that only class=
es within your own module will be able to touch them. Again, major props to=
 this proposal over Friends classes.</div><div><br></div><div>3- Class auto=
load vs Function autoload. There have been hundreds of hours spent on discu=
ssing function autoloading. I don&#39;t quite remember why that is such=C2=
=A0a hot topic and I also don&#39;t remember what it tries to accomplish, b=
ut it seems adjacent enough to consider that maybe this proposal could be a=
 door on that realm as well.</div><div><br></div><div>4- Familiarity with t=
he Typescript ecosystem. For better or worse, browsers run on Javascript fo=
r 3 decades and not even Wasm is fully changing that. This proposal is too =
familiar from Typescript&#39;s import / export system and would help bridge=
 the gap for frontend engineers to better understand the flow of PHP code.<=
/div><div><br></div><div>-----------</div><div><br></div><div>I haven&#39;t=
 read (or don&#39;t remember) the old discussion. From a superficial look o=
f 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&#39;m no=
t sure the syntax would require a full hard keyword reservation? Perhaps yi=
eld is good enough instead of export, but `use require` does seem rather od=
d. import ... require (as opposed to import ... from) would also work bette=
r-ish. In any case, this threads in bikeshedding space. I guess I&#39;d rat=
her have use .... require anyway than not have it at all, specially since I=
DEs often end up writing it for us anyway.</div></div><div><br></div><span =
class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gm=
ail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</di=
v></div></div></div></div></div></div></div></div>

--00000000000098112206344e5763--