Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124194
Precedence: bulk
MIME-Version: 1.0
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <CADK1yX+E9mvaM_CHJ8tmEx=O70hf8xasbvngh4wvNM8ce8KKGQ@mail.gmail.com>
 <B5DC69B8-E044-47FB-B81C-307E2C19CB66@newclarity.net> <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk>
 <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com> <CAEUnE0fNxSHN4QGfm6ETMVdE5Mcm1AEebmWs7i9xDNgcWnvQvw@mail.gmail.com>
 <39B496F8-062E-4848-9B3B-529BE8D3415A@newclarity.net> <CAEUnE0fOfU1tJNKXuBqbSm8jsp7gqe_JY-SiipdUKNztcx0Rog@mail.gmail.com>
 <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net> <CAEUnE0c0fW9xnQOtLgj1zTpvdfixSHuLeLA7HOqDTkpr4hJ84g@mail.gmail.com>
 <CAEUnE0dSUY2VKji_o-AgQ-YZMf7viwCZh1sa8ScHdS7ihUgfUQ@mail.gmail.com>
 <CAL0xaBFWUkeMk=ofOF4q+keVN6X3nx67NjZ1-2zWfgGez1oy4Q@mail.gmail.com>
 <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <4D45294E-78BA-466A-B2B4-F17BA4E1ED73@woofle.net>
 <6C3C9DCE-0DC8-4470-AE2B-28E550E08774@miles.systems> <3670820f-1f2f-4a19-9d30-183696e6a852@alec.pl>
In-Reply-To: <3670820f-1f2f-4a19-9d30-183696e6a852@alec.pl>
Date: Wed, 3 Jul 2024 08:58:32 -0400
Message-ID: <CAEUnE0fCdT-fcCkBi9Fx7+OsTPsegAp4OLbu08MK_vsNw5odLQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial
 Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e2ab04061c576399"
From: tendoaki@gmail.com (Michael Morris)

--000000000000e2ab04061c576399
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 3, 2024 at 7:49=E2=80=AFAM Aleksander Machniak <alec@alec.pl> w=
rote:

> On 3.07.2024 07:32, Richard Miles wrote:
> > What if php implicitly prepended namespaces with the composer package
> version?
> > If two incompatible versions are required, the composer downloads both.
> Enabled/Disabled with flag?
>
> While we're brainstorming... What if something like this would be possibl=
e?
>
> include $file with (strict_types=3D1, scope=3D$prefix);
>
> Composer would be able to do something useful with that, I suppose.
>
>
I would prefer to leave sleeping dogs where they lie - that is not change
how include, include_once, require and require_once work.  For one, code
imports are never optional, so the two include statements are NEVER
appropriate. Second, symbol definitions are never to be done twice, so
require is NEVER appropriate.  That leaves require_once, and having it
behave differently from its siblings is asking for confusion.  Hence the
reason I'd rather dispense with them entirely and move to a new import
mechanism entirely - import.  And since it's a new import mechanism it
could clean things up that cannot be cleaned any other way. I've tried to
stay away from that in the last few emails, but it is there. At a
minimum in my opinion, import should be a "code first" importer and not
require the file to be imported use <?php to get into code mode. If this
means using a separate extension for these files such as phm so that the
IDE's can figure it out (and so can users at a glance) so be it.  But the
behavior of the import statement is parallel to the package issue itself -
that is import files could be nothing special and the package mechanism
would still be a feature worth targetting.

--000000000000e2ab04061c576399
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 3, 2024 at 7:49=E2=80=AFA=
M Aleksander Machniak &lt;<a href=3D"mailto:alec@alec.pl">alec@alec.pl</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3.=
07.2024 07:32, Richard Miles wrote:<br>
&gt; What if php implicitly prepended namespaces with the composer package =
version?<br>
&gt; If two incompatible versions are required, the composer downloads both=
. Enabled/Disabled with flag?<br>
<br>
While we&#39;re brainstorming... What if something like this would be possi=
ble?<br>
<br>
include $file with (strict_types=3D1, scope=3D$prefix);<br>
<br>
Composer would be able to do something useful with that, I suppose.<br><br>=
</blockquote><div><br></div><div>I would prefer to leave sleeping dogs wher=
e they lie - that is not change how include, include_once, require and requ=
ire_once work.=C2=A0 For one, code imports are never optional, so the two i=
nclude statements are NEVER appropriate. Second, symbol definitions are nev=
er to be done twice, so require is NEVER appropriate.=C2=A0 That leaves req=
uire_once, and having it behave differently from its siblings is asking for=
 confusion.=C2=A0 Hence the reason I&#39;d rather dispense with them entire=
ly and move to a new import mechanism entirely - import.=C2=A0 And since it=
&#39;s a new import mechanism it could clean things up that cannot be clean=
ed any other way. I&#39;ve tried to stay away from that in the last few ema=
ils, but it is there. At a minimum=C2=A0in my opinion, import should be a &=
quot;code first&quot; importer and not require the file to be imported use =
&lt;?php to get into code mode. If this means using a separate extension fo=
r these files such as phm so that the IDE&#39;s can figure it out (and so c=
an users at a glance) so be it.=C2=A0 But the behavior of the import statem=
ent is parallel=C2=A0to the package issue itself - that is import files cou=
ld be nothing special and the package mechanism would still be a feature wo=
rth targetting.=C2=A0</div><div><br></div><div><br></div><div>=C2=A0</div><=
/div></div>

--000000000000e2ab04061c576399--