Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124109 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 B08011A009C for ; Sun, 30 Jun 2024 15:38:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719761999; bh=R1pFpGvXTOIIWo9VGHE8l6f44MqFZJnJhFDnQxzYD2c=; h=References:In-Reply-To:From:Date:Subject:To:From; b=Eb7qBllKPvh5ZR5MTiao0cNP1CGlUxyjN45/E+HjchrHCpvOR6gzucw3d+xKEkuxP GXrv7XaSPqWInWSf4dBH+0N+RRqPojCgOnago8GjquMbbYMQIxFwckjF2BDRWFenyO LyKo8ZE2z0IvbMrAfV65FCAB/k1nDfRgNbAiciOWwWJrU5alkFWRaUTgNiC/MoQfDo m//W1FY5QlD4t9OZYPyfH7qcsCHfrV45J17mJX+jDsvWSTNHMVoxtMs13nwZxJudXu vcdpt+MX+mBJ4i3NnsaSH5ykoLirglPKPFeLaoe/8hWfCEfqM+JdxkOIYZ6VDssHks OM1F2OK6iqRng== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A2EB8180A47 for ; Sun, 30 Jun 2024 15:39:58 +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-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 ; Sun, 30 Jun 2024 15:39:58 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-6b5031d696dso11938396d6.3 for ; Sun, 30 Jun 2024 08:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719761917; x=1720366717; 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=w6RMoHBoC4bRmHNj2MT2ZtZHs/CgVPzT44x9a9cxU+o=; b=LeYjsAspa73Xtn/XKyLOI4BXkse7wEKWlSi1z2uJd7bIiN+QpzX8KjUpMEME//JI5e N6K0kvyPrJHue7kQET9DoLEO/N1fTYwsBvUNxiGPLcMQTLnxi4o5xOxJ4kjAd+DxRN5W Ub/VTNvtZYz4tyNnHoUmqw3HVabyQJARbVrLp7i4yDFw18+bjMf7t85NMudOC3M1/CKh wG09+yoIYjW/cOSkAp9UljSdHTWjwghd5g9w+HCjyG5kxV5YgQqha/7CWNphfpdZ9HeM Wvhbdl894Ow3BzL3NZ97FsgZc2MJfMDYPZXra/SwimcZk5Fa6MJY2bst+ZrI+s/EBHXq dkMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719761917; x=1720366717; 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=w6RMoHBoC4bRmHNj2MT2ZtZHs/CgVPzT44x9a9cxU+o=; b=PgDkeokrLqDlRIyiSYOKjDh45ojUGPSRkJreQBWMtkKkDV16kFDi5YwIuppPXjP2SN RVo2WYBxzl/7gqQnxmfB/PNEvoTocb2aFRvHPfJ0bQbLe2ys9yCsDo4saqFvRHQa4xjc YLGk9GvAKKFZE1KVImFDqHxLgSlE6wAQImiyv7nIJgKuim7UaIwTRCmFfysAnMFpcU2o cIHb2DZGhtAq369hYSTEPlIr7rraupxTUQdzoWZ2gBeX+tQxjwfCr+zXLcM/Q6yu5yjo D4ZyF61gRKc4G7uVP6EgJbCffB97Nth3hS56Xem2Whzxph9aYimyqJa3g7EPTsroYTy5 Eo7A== X-Forwarded-Encrypted: i=1; AJvYcCXB5ZzKYAXVTQ3tXQzvRqRKU6V5c6L4rezltajZKC1EiSXQeoZ5UYj3hvOTAN8g5HgESmRIqW2yAauNZYgS8ZTeHqKb2Qv0YA== X-Gm-Message-State: AOJu0Yz2OxShuBzFPxOcJrqAakCwRZgKBA3tYSSgOpMUsbkQG1uF0cXK YPf85A7U4gSN5YBqT/4owipgdMJRt8NTeQn9o6aHu2cqeHL4h//IcDB+vASkjEDzd5WbxurUOZZ pKrPkvuLH8TH7ORyyFyUH5pYj/Sk= X-Google-Smtp-Source: AGHT+IEWEq96ED5aY7VLHPdlCBdSMhnxOwJcdgYUgJKvcehPmOPvWeRFQtwRC6RnHL8v05de19+NBvQI4UVdvRjPY74= X-Received: by 2002:a05:6214:2a89:b0:6b5:63b:de4f with SMTP id 6a1803df08f44-6b5b7083732mr42053046d6.15.1719761917505; Sun, 30 Jun 2024 08:38:37 -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> <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net> In-Reply-To: <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net> Date: Sun, 30 Jun 2024 11:38:25 -0400 Message-ID: Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript To: Mike Schinkel , PHP internals Content-Type: multipart/alternative; boundary="00000000000030f78d061c1d460e" From: tendoaki@gmail.com (Michael Morris) --00000000000030f78d061c1d460e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no proposal. I'm brainstorming. Please don't step out of this conversation as it has been enormously helpful. On Sun, Jun 30, 2024 at 2:48=E2=80=AFAM Mike Schinkel = wrote: > > On Jun 29, 2024, at 10:57 AM, Michael Morris wrote= : > > 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 onl= y > 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 > project (the index.php file). Trying to keep it simple in this early sket= ch > 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 tha= t > 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, an= d > 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 a= ll > 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 nee= ds > 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 th= e > two dependencies. > > > > That said, I wonder if incorporating versioning does not make the scope > of 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 piec= es > 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. > > After some private time spent documenting my thoughts on modules I > realized my thoughts have diverged from your proposal, so rather than > challenge any of your arguments I will just demure and work on my own > contribution. > > I discovered the need for a small new feature that would generally be > incredibly useful but also could empower userland to create their own for= m > of modules, and that feature proposal will be much smaller in scope > compared to one for your concept of modules. It may or may not be > orthogonal to the discussion you are leading. > > -Mike > > --00000000000030f78d061c1d460e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no proposal. I'm brainstorming. Please don'= t step out of this conversation as it has been enormously helpful.
On Sun, J= un 30, 2024 at 2:48=E2=80=AFAM Mike Schinkel <mike@newclarity.net> wrote:
> On Jun 29, 2024, at 10:57 AM, Michael= Morris <tendoak= i@gmail.com> wrote:
> On Sat, Jun 29, 2024 at 5:40=E2=80=AFAM Mike Schinkel <mike@newclarity.net> wr= ote:
>> 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 bein= g generated =E2=80=94 whereas every directory with Go code is a package (wh= ich I think is equivalent to what you are calling "module."
> In my examples I have a local developed module being consumed by a pro= ject (the index.php file). Trying to keep it simple in this early sketch ou= t.
>=C2=A0
> So I think your use of them here is conflating the two concepts. One i= s 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.= =C2=A0 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.
>=C2=A0
> Also, it is problematic to have `php.mod` and `php.sum` because web se= rvers would serve them if not carefully configured hence why I went with a = leading dot, e.g. `.php.module`
>
> This is a tree detail. Working on the forest overall right now. Not th= at it's wrong, but leading dots to hide files is a .nix feature that do= esn't work on Windows (though applications 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.:
>
> <?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 ha= ving `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 hi= storical reasons. Plenty of people on this list can explain how and why, bu= t suffice to say namespace declarations have no effect on variables, and va= riables declared outside functions go into the global scope - which is a re= al trainwreck of a place in long lived applications. Wordpress, for example= , has a FRIGHTENING number of global variables, and they aren't namespa= ced (they are prefixed, but that only goes so far).
>
> Modules have their own variable scope. They don't affect the globa= l 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 lat= er.=C2=A0 They are also going to need their own symbol scope in case one mo= dule 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 betwee= n the two dependencies.
>
> That said, I wonder if incorporating versioning does not make the scop= e of modules too big to complete?
>
> In my experience it's best to get a roadmap in place - which is wh= at 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 wit= h namespaces like that, but I am replied out for the night. :-)
>
> I'm not sure we can completely abandon the concept of namespaces s= o in this version of the proposal I incorporated them since, in the initial= ramble I ignored them.=C2=A0 Where they land is as of yet an open question= .

After some private time spent documenting my thoughts on modules I realized= my thoughts have diverged from your proposal, so rather than challenge any= of your arguments I will just demure and work on my own contribution.

I discovered the need for a small new feature that would generally be incre= dibly useful but also could empower userland to create their own form of mo= dules, and that feature proposal will be much smaller in scope compared to = one for your concept of modules.=C2=A0 It may or may not be orthogonal to t= he discussion you are leading.

-Mike

--00000000000030f78d061c1d460e--