Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124372 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 D7EB21A00B7 for ; Wed, 10 Jul 2024 20:04:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720641985; bh=2gwdGjEsM3xZODmds/xMd0nh7ynibegPisCCvOYBn2w=; h=References:In-Reply-To:From:Date:Subject:To:From; b=NqIyWfrAubA9tfEvg/X3AGyy7sD7ealxeZJTjLuxGMK+TDFCWB29B95Y4HLBir3MP Qi04PYelx5spbm1iYvBMua1rjNX9yWlzJBmORXdO93hyvagp1+hexpHsXDHeQReQLi S2iO9wDOZaSgEKbMmLWfMP4YpXh81xgNVyBgkHMg7rHWyhWYWecGYXzsKUQgMQg2ic JU3dwrRTdR9KFyp0Zvl1ho4SiG/HY2budA4ry+ng+iCcWW21f8w+2SlGhJqQLp65oU bBzH7UgTDZDGXNWO3oPglpMhXLLVBuWfy/Td0hQE9llT218p6FoTWZx3u9Tly3XUy2 Ajj90FINTonGg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0E009180785 for ; Wed, 10 Jul 2024 20:06:22 +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_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 ; Wed, 10 Jul 2024 20:06:20 +0000 (UTC) Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-70364e06dc6so63501a34.0 for ; Wed, 10 Jul 2024 13:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720641893; x=1721246693; 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=RvqHb/i817VajSl1g72hmrIKJWxB5OewewVvpZHVNWA=; b=BzJQJP2HxHNcM3cEANr1ge3pkQpzxEk8xfy+g7jlrzSl/ObSuWHRpZKb2OY8soDWcS kFdDKy4GD40JgwE31IC7RpvefIV0pV3Hnd25nSdACYTpsunBb66ftUn6gOOU/3a6Reu8 jlgokSvLIiBhR5dT4bPCBaMJ+siEwZGB9cQYokw0291wsyneAcZ0ZNYJpjoYC2DenPQn ApM8OyW/VO0gCF8S4CtcyzXsJ+4FZK85d02roGW37lRXjV6k9ZhKmIJuBfAWeLEgbGKK JYAaIP2qigI4aalOZgV1sbI7EAFqIdScre6VzSnHbkTBpYv538lOREN8xJFPT8NSVzdE CDuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720641893; x=1721246693; 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=RvqHb/i817VajSl1g72hmrIKJWxB5OewewVvpZHVNWA=; b=vG00QzgNvMpn7V8bV5Vi/lEOzzbp93Af8l/BCjKKLdEB5kuKcxNCbYY/f6daktswQE eN3dN94WbOKVBPVRPrVn6IcFzJaFR1WGeZl/AGjTr9hHoVTph/nPyvjdVA3pPnm7DC6I fQWXgYf1lZbPCX3D2rr3QGMpxkNh8n8hzmb1C2O+86viHnnTcNPN7vhHwVK0y0kqKmf4 wQyl/jEwBeusaswclEm4dKRSxv/Me2zzEUWTvsZDQPkuu+4564QWQvrubtnP+l/0pVx0 vNfvF55xKEDmupjcpkUciOzuOZErf7GuF3MPEwOS0TkAkH7favrDKA6npYcRNau2xapa R+Ow== X-Gm-Message-State: AOJu0YymhBlZPKB08cfQYf2qisVY3H6g0pJOjJBn8SvW7VfCiDEIDxea 8km5AlakitGmTKOOutKormL+srYHd2uazzsstEEcdBL6iyg1hPiP4ZwTqIW7fPV/krNxzZZGpoB Oz8sBh0BfaYxmUjUvjng0vg14tefoFPOe X-Google-Smtp-Source: AGHT+IFnczkf/rpwQNM3FRpmPrxfOgXrdYF6LBK0VXuAXOGqaL93E9uhiI4Mgf1FKEtydr3nlIS358UDEnkyZFuCJp0= X-Received: by 2002:a05:6830:2043:b0:703:69b5:1518 with SMTP id 46e09a7af769-70375a08669mr6687919a34.16.1720641893026; Wed, 10 Jul 2024 13:04:53 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com> <1BE6A849-A2A9-4E17-9C11-5099EF74F5C0@rwec.co.uk> <1d0df8f2-541a-4302-a658-4d7d30003342@seld.be> <1D89C00E-ED0F-4862-A958-AC9D085E91F3@rwec.co.uk> In-Reply-To: <1D89C00E-ED0F-4862-A958-AC9D085E91F3@rwec.co.uk> Date: Wed, 10 Jul 2024 16:04:41 -0400 Message-ID: Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV) To: PHP internals Content-Type: multipart/alternative; boundary="000000000000d1d694061cea280c" From: tendoaki@gmail.com (Michael Morris) --000000000000d1d694061cea280c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2024 at 3:29=E2=80=AFPM Rowan Tommins [IMSoP] wrote: > > > On 10 July 2024 19:08:39 BST, Michael Morris wrote: > > Just to repeat a point that's been raised a few times: this is not a grea= t > time of year for this kind of discussion. If you come back after 8.4 is > baked, you may get more enthusiasm. That will also give you time to make > some more detailed analysis, so we don't have to argue about hypothetical > difficulties. > I'm in no rush - though it might not seem that way. I don't see this being able to land before PHP 10. I'm pessimistic about the scope of these changes. It can be done - and pieces have often been discussed before, but they peter out. If they are to be solved some amount of stupid bulldog tenacity will be needed. I think I'm stupid enough to provide that, but I need to do it without being annoying. In any event these threads have already shown me a great deal of what I need to learn in order to get to an effective final form, whatever that is. > > >1. Import Maps - These would be prepared by hand or by a package manager > >like composer. > > As Larry mentioned, there was a proposal for this a while ago, but not > much enthusiasm, since it's so easy to implement in userland, and doing s= o > means we don't have to include all the possible options someone might wan= t. > > > > it will be able to detect symbols the autoload > >system cannot: functions and constants. > > Autoloading functions and constants isn't blocked by autoloaders being > procedural, it's blocked by the unfortunate decision made many years ago > that a function call like "strlen" dynamically falls back to meaning > "\strlen", rather than being resolved once at compile-time like class > names. > So far, nobody's quite cracked how that should interact with autoloading. > Don't expect this to be easy. > At worst this is the sort of "unfortunate decision" that can be eschewed in the PHP module files to make them easier to work with. But I really do need a list of these things we'd love to do but can't because of reasons. > > >2. Packages - Packages load differently and can effectively monkey-type > the > >code of an existing package on the fly in much the same way that > namespaces > >themselves work with symbol names as a flat string replace. > > This is an interesting - but extremely complex - problem, and the one I'v= e > been urging you to focus on if you're really up for the challenge. It > probably needs quite a deep dive into how the language works to find out > what assumptions it's going to break. (If you're just going to talk about > configuration, and not the actual implementation, don't expect much > enthusiasm.) > I need to know where to start, beyond cloning the PHP source code repo - which I have. Any advice on where to look would be appreciated. > > > > Existing code > >can be loaded into packages, but also an outline for writing packages th= at > >have privacy modifiers to their members - i.e. protected class SomeClass > {} > > This part seems interesting, as long as it's not tied heavily into other > changes; existing code using /** @internal */ should ideally need minimal > changes to make use of it. > > > > >3. Modules - Files which are code first instead of template first. > > If by "template first" you mean "you have to write repeat my earlier "meh". I'm pretty sure it's also been discussed before, > and dropped when it met with that general reaction. > > The name "modules" implies something more, so maybe I should reserve > judgement. Having both "packages" and "modules" sounds pretty confusing > though. > The largest thrust of modules is to step forward with changes that are desirable but impossible to implement because of BC breaks brought on by unfortunate design decisions like the one mentioned previously. Likely these will be visited on a case by case basis. For another is the need of classes to have the function keyword all over the place. It could end up that things like package privacy can only be supported in the modules. As to the difference, since it meanders all of the place here's the defs I'm going with - A module is a file. A package is a collection of files. --000000000000d1d694061cea280c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 10, 2024 at 3:29=E2=80=AF= PM Rowan Tommins [IMSoP] <imsop.= php@rwec.co.uk> wrote:


On 10 July 2024 19:08:39 BST, Michael Morris <tendoaki@gmail.com> wrote:

Just to repeat a point that's been raised a few times: this is not a gr= eat time of year for this kind of discussion. If you come back after 8.4 is= baked, you may get more enthusiasm. That will also give you time to make s= ome more detailed analysis, so we don't have to argue about hypothetica= l difficulties.

I'm in no rush - th= ough it might not seem that way. I don't see this being able to land be= fore PHP 10. I'm pessimistic about the scope of these changes. It can b= e done - and pieces have often=C2=A0been discussed before, but they peter o= ut. If they are to be solved some amount of=C2=A0stupid bulldog tenacity wi= ll be needed. I think I'm stupid enough to provide that, but I need to = do it without being annoying.=C2=A0=C2=A0

In any e= vent these threads have already shown me a great deal of what I need to lea= rn in order to get to an effective final form, whatever that is.
= =C2=A0

>1. Import Maps - These would be prepared by hand or by a package manage= r
>like composer.

As Larry mentioned, there was a proposal for this a while ago, but not much= enthusiasm, since it's so easy to implement in userland, and doing so = means we don't have to include all the possible options someone might w= ant.


> it will be able to detect symbols the autoload
>system cannot: functions and constants.

Autoloading functions and constants isn't blocked by autoloaders being = procedural, it's blocked by the unfortunate decision made many years ag= o that a function call like "strlen" dynamically falls back to me= aning "\strlen", rather than being resolved once at compile-time = like class names.=C2=A0

So far, nobody's quite cracked how that should interact with autoloadin= g. Don't expect this to be easy.

At= worst this is the sort of "unfortunate=C2=A0decision" that can b= e eschewed in the PHP module files to make them easier to work with.=C2=A0 = But I really do need a list of these things we'd love to do but can'= ;t because of reasons.
=C2=A0

>2. Packages - Packages load differently and can effectively monkey-type= the
>code of an existing package on the fly in much the same way that namesp= aces
>themselves work with symbol names as a flat string replace.

This is an interesting - but extremely complex - problem, and the one I'= ;ve been urging you to focus on if you're really up for the challenge. = It probably needs quite a deep dive into how the language works to find out= what assumptions it's going to break. (If you're just going to tal= k about configuration, and not the actual implementation, don't expect = much enthusiasm.)

I need to know where = to start, beyond cloning the PHP source code repo - which I have.=C2=A0 Any= advice on where to look would be appreciated.
=C2=A0


> Existing code
>can be loaded into packages, but also an outline for writing packages t= hat
>have privacy modifiers to their members - i.e. protected class SomeClas= s {}

This part seems interesting, as long as it's not tied heavily into othe= r changes; existing code using /** @internal */ should ideally need minimal= changes to make use of it.



>3. Modules - Files which are code first instead of template first.

If by "template first" you mean "you have to write <?php = at the top", I repeat my earlier "meh". I'm pretty sure = it's also been discussed before, and dropped when it met with that gene= ral reaction.

The name "modules" implies something more, so maybe I should rese= rve judgement. Having both "packages" and "modules" sou= nds pretty confusing though.

The larges= t thrust of modules is to step forward with changes that are desirable but = impossible to implement because of BC breaks brought on by unfortunate desi= gn decisions like the one mentioned previously.=C2=A0 Likely these will be = visited on a case by case basis.=C2=A0 For another is the need of classes t= o have the function keyword all over the place.

It= could end up that things like package privacy can only be supported in the= modules.=C2=A0 As to the difference, since it meanders all of the place he= re's the defs I'm going with - A module is a file.=C2=A0 A package = is a collection of files.
--000000000000d1d694061cea280c--