Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123955 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 1464B1ADBF6 for ; Thu, 27 Jun 2024 19:23:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719516277; bh=1sDQFq73klNWK12A3YbRzw9RVKqE3LUwtxwogCA3mYk=; h=References:In-Reply-To:From:Date:Subject:To:From; b=M/QS6t+fyG/PcJ9ESWvWaS8XeJiLeGSLEggsG63ZNKyYKRp4rsF62yKkteNPLxLHJ LHKcW/a9CJNjppdlyPBZcp4yjU/WNuLcp3GUumBAQpFLOFqWpNFF21yis1C1uj5wzv oVgjQG59T4Jpi2XVOc0GwgjUEMBqidqWXGvpEHdmp87bK5ypKS0n4Ch0pf7lNOGDYh yBXFpM5FsP2aZRt8XseGkuB7OjE0dHm/ui+1RvYYzYYlNnk973A1HOTRjGbHGPa6J6 wH10pjCQK4I+Py31fX7Ypmmf8t3gpQk6fyZ78NgkDqL0QoJRZZ0aZ92GphgF9Abz9K MfDm3mbKOWFXw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 99EF5180587 for ; Thu, 27 Jun 2024 19:24:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 27 Jun 2024 19:24:31 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-57d203d4682so2443146a12.0 for ; Thu, 27 Jun 2024 12:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719516191; x=1720120991; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=iXvYRtEejUN2QriosZJpiASAj2BqHvuoQ6VYdox3zg0=; b=Y7J585lasJyvyduKFLuCIZmd9C7psH4j8UkdSpnig7YC/d14uNk/sWZ5GRU67k2BzM LTaYOPDwjE8yDQTCjZGC0fsdFy7O4VGsCetuHIKPvjoH3vvdsWBnwYvZIKwNmPhG0rvI xCk0twMXCHlbR5kT1eAaH1QxhcKlHBirLRp40eWKz2gAhCmuIQc4UCC6cA1pXxR7vfCK oMmdXPzcDHYsL6cVz1JxMzwMdUtPt8g8j7wDLUxEf8yqFKtJK7YQjIlDEmqnCzpihz7W d7r4ulGsaW0CmCIp/eWL6JxYIEoJ4wCgYQ+IMjzq03xgYUWVBQUN27HNBrIlH36m4KxQ 6nug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719516191; x=1720120991; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iXvYRtEejUN2QriosZJpiASAj2BqHvuoQ6VYdox3zg0=; b=HnK5aAFHBsPRihli+Cij5mnRzXmdSrxIn3CI8R+GAh319Qurfy+E3PS4zuq/w7abPZ ntEIf7+5J1WrM2sZxuXdP6kXtsnZvp/ZkD1dIBF1s/x6TbN1ObY63PYHc1fk+8q69m1N 7/FyWhim0MIfRJ+HcVuK3jSEswoPowPngG64qSxWPP8DnMHuIu1FmGb85QMMiXmRHRCN TUyQmTDOdcqtqws8lun4Oofv08W75sturW1GDxyF6dGDOzXbejl6+V3eFdFn5nJCJlOg DdpCrHlT6nbnPByFjP3HiRsYuqNW4zFKEILhRykW73BmMdkbL5QcBlGnjV+MXl9ziLuf NzQQ== X-Gm-Message-State: AOJu0YzswModwIoHXWYIyVi37f0DBR+v/CH3EyEZo2110UcvwOVIqNce GSNtQHVN6qaBIbzA2/NiDpHqJslMR8ZwxJXe7AdMzdAyL9IcYcN2dPuw6rA9QpwlNZfWOkniEfr VSd7JUvKBj5VMBEYO/YLN1vxrzVJ4Sg== X-Google-Smtp-Source: AGHT+IHCJYuG+zZHG9KJ+IMaQdpG0RPz8SHblvUP39UrzPQVg0R8PrPzRCNJKtf9sZmHSjzgHjAfJ5uzSYrBV2bU+iM= X-Received: by 2002:a17:906:bf49:b0:a72:4756:bd32 with SMTP id a640c23a62f3a-a724756be7amr939668766b.48.1719516190504; Thu, 27 Jun 2024 12:23:10 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 27 Jun 2024 15:22:58 -0400 Message-ID: Subject: Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript To: PHP internals Content-Type: multipart/alternative; boundary="000000000000b87d97061be40f86" From: tendoaki@gmail.com (Michael Morris) --000000000000b87d97061be40f86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2024 at 2:11=E2=80=AFPM Deleu wrote: > Who would build it is an extremely key aspect of making changes to PHP. > Ideas are hard enough to survive the RFC process when there's already an > implementation. Finding a sponsor to work on this would be the first step= . > Agreed. > > Given that ini settings are frowned upon nowadays, I think having a ` declare(modules=3D1);` for the initial file might make the idea more like= ly > to pass a vote? Or maybe I'd even try to go one step further and say that > whatever file is being executed by SAPI (the first PHP file) could be > interpreted with a dumb lookahead. If the file has import / export syntax= , > treat it like PHP Module, otherwise fallback. > MKS Archive already pointed out that even this is unecessary. Just let the landing file import the modules, even if that means it's a one line file. > > I'm not familiar enough with Javascript / Typescript ecosystem, but I've > only ever seen / used the ability to import using direct filepath. > In the clientside up until recently direct filepath was the only way. That changed with import maps https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/impor= tmap NodeJS has been doing something similar serverside for much longer with CommonJS requires, which predate by a good 5 years the ES6 mechanism. As a serverside language it now has to juggle both. The resolution path I sketched out is based on how NodeJS works. Can that be improved upon? Likely - it is confusing > The fact there's weird behaviors as result of trying to import a file and > suddenly a file all the way from `include_paths` or `php_modules` seems > like a no-go to me. I'd favor using only simple file path navigation and = if > the file doesn't exist, error. > > Perhaps if the idea gains merit, Composer could offer something similar t= o > Vite where we can create an alias to a specific folder and then import > things like `from '@package/path/to/file`. > Composer would need a massive rewrite to be a part of this since it currently requires the file once it determines it should do so. If we do a system where import causes the parser to act differently then that alone means imports can't be dealt with in the same manner as other autoloads. > > >> This will of course require a package manager similar to composer to >> become part of core. However, composer will not be eclipsed as the impor= t >> package manager (phppm?) is only concerned with user modules. These modu= les >> must explicitly export any symbols being fetched from them, whereas >> composer will continue to load files using require. >> >> Imports can also be done against directories >> >> ``` >> import foo from "mypackage" >> ``` >> >> In this case the parser will look for "mypackage/index.php" >> > > I'm not fond of this either. > > There will need to be a way to define the entrypoint php. I think index.php is reasonable, and if another entry point is desired it can be called out -> "mypackage/myentry.php" > ---------------- > > Overall, I think PHP has already reached the limit of surviving with only > PSR-4 and Composer. Single class files were a great solution to get us ou= t > of the nightmare of `require` and `import` on top of PHP files. But more > than once I have had the desire to declare a couple of interfaces in a > single file, or a handful of Enums, etc. It seems like PHP Modules could > also address the issue with function autoloading and package-level > visibility. I like the idea but I'm a bit skeptical until we have some > buy-in from someone that could actually get this implemented. > That would be one of the larger hurdles, if not the largest. --000000000000b87d97061be40f86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 27, 2024 at 2:11=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:
Who would build it is an extremely key aspect of = making changes to PHP. Ideas are hard enough to survive the RFC process whe= n there's already an implementation. Finding a sponsor to work on this = would be the first step.

= Agreed.
=C2=A0

Given = that ini settings are frowned upon nowadays, I think having a `<?php dec= lare(modules=3D1);` for the initial file might make the idea more likely to= pass a vote? Or maybe I'd even try to go one step further and say that= whatever file is being executed by SAPI (the first PHP file) could be inte= rpreted with a dumb lookahead. If the file has import / export syntax, trea= t it like PHP Module, otherwise fallback.

MKS Archive already pointed out that even this = is unecessary. Just let the landing file import the modules, even if that m= eans it's a one line file.
=C2=A0

I'm not familiar enough with Javascript / Typescript e= cosystem, but I've only ever seen / used the ability to import using di= rect filepath.

In the cl= ientside=C2=A0up until recently direct filepath=C2=A0was the only way. That= changed with import maps


NodeJS has been doing som= ething similar serverside=C2=A0for much longer with CommonJS requires, whic= h predate by a good 5 years the ES6 mechanism. As a serverside=C2=A0languag= e it now has to juggle both.

The resolution path I= sketched out is based on how NodeJS works. Can that be improved upon? Like= ly - it is confusing

=C2=A0
The fact there's weird behaviors as result of trying to import a= file and suddenly a file all the way from `include_paths` or `php_modules`= seems like a no-go to me. I'd favor using only simple file path naviga= tion and if the file doesn't exist, error.=C2=A0

Perhaps if the idea gains merit, Composer could offer something similar = to Vite where we can create an alias to a specific folder and then import t= hings like `from '@package/path/to/file`.

Composer would need a massive rewrite to be a part of = this since it currently requires the file once it determines it should do s= o. If we do a system where import causes the parser to act differently then= that alone means imports can't be dealt with in the same manner as oth= er autoloads.
=C2=A0
=C2=A0
This w= ill of course require a package manager similar to composer to become part = of core. However, composer will not be eclipsed as the import package manag= er (phppm?) is only concerned with user modules. These modules must explici= tly export any symbols being fetched from them, whereas composer will conti= nue to load files using require.

Imports can also = be done against directories

```
import f= oo from "mypackage"
```

In thi= s case the parser will look for "mypackage/index.php"
=

I'm not fond of this either.


There will need to = be a way to define the entrypoint php.=C2=A0 I think index.php is reasonabl= e, and if another entry point is desired it can be called out -> "m= ypackage/myentry.php"
=C2=A0
----------------

Overall, I think PHP has= already reached the limit of surviving with only PSR-4 and Composer. Singl= e class files were a great solution to get us out of the nightmare of `requ= ire` and `import` on top of PHP files. But more than once I have had the de= sire to declare a couple of interfaces in a single file, or a handful of En= ums, etc. It seems like PHP Modules could also address the issue with funct= ion autoloading and package-level visibility. I like the idea but I'm a= bit skeptical until we have some buy-in from someone that could actually g= et this implemented.

That= would be one of the larger hurdles, if not the largest.=C2=A0
<= /div> --000000000000b87d97061be40f86--