Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124038 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 0CCC51ADC88 for ; Sat, 29 Jun 2024 15:10:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719673927; bh=2WfcMo9jLqdRobDYrZre/oOq+watU1qS/UuTZobrzdg=; h=References:In-Reply-To:From:Date:Subject:To:From; b=EfzkOWEPZPx905sO4ORNwMa9ZqVGxlsH8eDT+hj4C86vmq0snlU+ZkCmFUWMtWcuo yCRl6resW2r5pIPvvUh27AhBde0zu5YSYP5I4Y3uL0VO8i+/gxNucnxk4qUSfR7YXa eQ/5W40WwgUlEfV/aOo1VA+tqbniOv9dXqfvfR7hdfT+3x20jZoRiQImCF77ccjjFw 2CMEv6ZqvbDJgw8iJuYZ0nR96baloDjZiaJ0rhjTcNixWhx7OsV5lM68HHbdxMR/av oXQh/HgrjX/FpCunf3Bf3tfKo5E2SbWhDaCnXuBM/tQnZu1T6mBRIADDILbQJBHw6s Jwbp+2mPHBlxw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 70E7F180FF0 for ; Sat, 29 Jun 2024 15:12:04 +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-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (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 ; Sat, 29 Jun 2024 15:12:01 +0000 (UTC) Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6b2c95b6c5aso6991346d6.2 for ; Sat, 29 Jun 2024 08:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719673841; x=1720278641; 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=jD9NHUW0AwIIB9Fq7erhVw7IJ7P2/oQ9u0us8gjoU2I=; b=K9uImPcZBUsWbyiznFckP0j4bqWStvTd/6UkvloOIMx9d4r68xSMLN6tRTyafFdP9V 4KXiWtlNAhdaMd6b+HBowr/fRm9od4bqFDhJEm+NmII48/x88Gw/lAOXxTocs18UOkxX 9ExpfXualfVo4QgHdaKQ92gH1gRJEjRi2M5sOGut7KqAiCtUDFXSiQjzaCuosZE2oOpc VP/lB8WK3HJBejg0bs356NFOzDWJzOXkm4C54O9yE51g0u01TRgNDKH7uPYIMrjcpvob Wl28ul3y0J6ix34gEq4ZdJxXbAH4+7Hg67DnlbsBlHenrC/3iANxXyk6U8R1VZn081sS xzAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719673841; x=1720278641; 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=jD9NHUW0AwIIB9Fq7erhVw7IJ7P2/oQ9u0us8gjoU2I=; b=ooFiNN7vKWC1DKiVMKrGXy3crZIvV0NCgT9/y/9N1m36yx71H3aT36n2izIv5bgNp9 flq06p1HZkdcj4BU5TCGikiyA7R9u43XC6E3k1Z9+GMRtYxiUD6x2lsHOdy/3RIzPN5h ogbPySesgNhaHgM6IHABvhPErRy0Ak8L4rxEobIGJ51R6l3dlt+ltLubK9r/MovkNxX+ BTVu+z7t1szLRdYg8Ud9YKHG0KjoEeKh+h5NJjPnhaAmxDzsYRFhmWzoXY3heezIl78R ATklhvOE/JaKt1NWCv/YNWMp9jgaYcczaOlSgjO0uoF4vvKGTuM2HBBMQlbAol3bJnRr ge1w== X-Gm-Message-State: AOJu0YxK94iscNZPFgmHkzRi8X42lqpBVdaUaOBGPRZ3ef31JmPuWRHG b07aNmeWeSX98Ef+xGpfsDMG6h1x8tpxTxz9INjPz6CA85/XBzsxXjQ3i+OwJADR/BEdZe+7zat 3g0CZxZA4V+fMsJUTkPVSiEthCAoExA== X-Google-Smtp-Source: AGHT+IHvrD78NYedbhAnTnTMoZ5RtzG0lv1Tr/zP1bVF1OVOx1Ofs6a35iCURz9MWeSKJleXFZxz6OvJEhAc3OMDWQg= X-Received: by 2002:a05:6214:ca5:b0:6b5:80f5:cae5 with SMTP id 6a1803df08f44-6b5b71caf29mr14831876d6.64.1719673840866; Sat, 29 Jun 2024 08:10:40 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk> <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com> <39B496F8-062E-4848-9B3B-529BE8D3415A@newclarity.net> In-Reply-To: Date: Sat, 29 Jun 2024 11:10:28 -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="0000000000006a1e5d061c08c43c" From: tendoaki@gmail.com (Michael Morris) --0000000000006a1e5d061c08c43c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 29, 2024 at 5:40=E2=80=AFAM Mike Schinkel = wrote: > However, be aware that in a Go project repo you are likely to have only > one `go.mod` =E2=80=94 or multiple if you have numerous CLI apps being ge= nerated =E2=80=94 > whereas every directory with Go code is a package (which I think is > equivalent to what you are calling "module." > > In my examples I have a local developed module being consumed by a projec= t (the index.php file). Trying to keep it simple in this early sketch out. > So I think your use of them here is conflating the two concepts. One is a > project-wide concept and the other is a "package" concept. > > I may well be. I'm looking for something that makes sense in PHP. Namespaces, for good or ill, are a part of php, which is why the php.mod in my example declares a namespace, not a package. > Also, it is problematic to have `php.mod` and `php.sum` because web > servers would serve them if not carefully configured hence why I went wit= h > a leading dot, e.g. `.php.module` > > This is a tree detail. Working on the forest overall right now. Not that it's wrong, but leading dots to hide files is a .nix feature that doesn't work on Windows (though applications ported from .nix to windows often continue to honor the convention). > Aside from being familiar per Javascript, what is the argument to > requiring the import of specific symbols vs just a package import, e.g.: > > > import "./src/mymodule" > > > mymodule->twig->render('index', ['name' =3D> 'World']); > > > To me is seems to just add to boilerplate required. Note that having ` > mymodule` everywhere you reference `twig` makes code a lot more > self-documenting, especially on line 999 of a PHP file. =F0=9F=99=82 > > PHP's variable table and symbol table are entirely separate for historical reasons. Plenty of people on this list can explain how and why, but suffice to say namespace declarations have no effect on variables, and variables declared outside functions go into the global scope - which is a real trainwreck of a place in long lived applications. Wordpress, for example, has a FRIGHTENING number of global variables, and they aren't namespaced (they are prefixed, but that only goes so far). Modules have their own variable scope. They don't affect the global scope at all and I don't think they should be able to import globals at all with the global keyword, but that sort of thing can be discussed later. They are also going to need their own symbol scope in case one module needs to run an older version of a dependency it would otherwise share with another module in the same project because there is a BC break between the two dependencies. > > That said, I wonder if incorporating versioning does not make the scope o= f > modules too big to complete? > > In my experience it's best to get a roadmap in place - which is what we're doing here - and THEN scope out the roadmap and determine what pieces go in over multiple versions > I don't think it is wise to intertwine this concept of modules with > namespaces like that, but I am replied out for the night. :-) > > > I'm not sure we can completely abandon the concept of namespaces so in this version of the proposal I incorporated them since, in the initial ramble I ignored them. Where they land is as of yet an open question. --0000000000006a1e5d061c08c43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024= at 5:40=E2=80=AFAM Mike Schinkel <mike@newclarity.net> wrote:
= However, be aware that in a Go project repo you are likely to have only one= `go.mod` =E2=80=94 or multiple if you have numerous CLI apps being generat= ed =E2=80=94 whereas every directory with Go code is a package (which I thi= nk is equivalent to what you are calling "module."
In my examples I have a local developed mod= ule being consumed by a project (the index.php file). Trying to keep it sim= ple in this early sketch out.
=C2=A0
So I think your use of them here = is conflating the two concepts. One is a project-wide concept and the other= is a "package" concept.

I may well be. I'm looking for something t= hat makes sense in PHP.=C2=A0 Namespaces, for good or ill, are a part of ph= p, which is why the php.mod in my example declares=C2=A0a namespace, not a = package.
=C2=A0
Also, it is problematic to have `php.mod` and `php.sum= ` because web servers would serve them if not carefully configured hence wh= y I went with a leading dot, e.g. `.php.module`

This is a tree detail. Working on= the forest overall right now. Not that it's wrong, but leading dots to= hide files is a .nix feature that doesn't work on Windows (though appl= ications ported from .nix to windows often continue to honor the convention= ).
=C2=A0
=
=
Aside from being familiar per Javascript, what is the argument to requ= iring the import of specific symbols vs just a package import, e.g.:
<= div>
<= ?php
import "./src/mymodule"

mymodule->twig->render('index', ['name' =3D> '= World']);

To me is seems to just add to boilerplate required.=C2=A0= Note that having `mymodule`=C2=A0everywher= e you reference=C2=A0`twig`=C2=A0makes code a lot more self-documenting, = especially on line 999 of a PHP file. =F0=9F=99=82
=

PHP's variable table and symbol table = are entirely separate for historical reasons. Plenty of people on this list= can explain how and why, but suffice to say namespace declarations have no= effect on variables, and variables declared outside functions go into the = global scope - which is a real trainwreck of a place in long lived applicat= ions. Wordpress, for example, has a FRIGHTENING number of global variables,= and they aren't namespaced (they are prefixed, but that only goes so f= ar).

Modules have their own variable scope. They d= on't affect the global scope at all and I don't think they should b= e able to import globals at all with the global keyword, but that sort of t= hing can be discussed later.=C2=A0 They are also going to need their own sy= mbol scope in case one module needs to run an older version of a dependency= it would otherwise share with another module in the same project because t= here is a BC break between the two dependencies.

= =C2=A0
That said, I wonder if incorporating versioning does not make t= he scope of modules too big to complete?

In my experience it's best to get a roadma= p in place - which is what we're doing here - and THEN scope out the ro= admap and determine what pieces go in over multiple versions

=
=C2=A0
I don't think it is wise to intertwine this concept of modules with = namespaces like that, but I am replied out for the night. :-)


I'm not sure= we can completely abandon the concept of namespaces so in this version of = the proposal I incorporated them since, in the initial ramble I ignored the= m.=C2=A0 Where they land is as of yet an open question.
=C2=A0
--0000000000006a1e5d061c08c43c--