Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124375 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 6A8121A00B7 for ; Wed, 10 Jul 2024 22:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720649824; bh=xHUb/Dsy1YGCx29+M1KHUlX0z9gGzLwa1+inxOqw4EI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MWHHIArDqIlUZa1VHcSgsyHV6hMJrtljDWXBExz404C+l8sirUvlU0ZZo+ZuJ5Zrb 9l96qOmeilVHsEeMqEpbnUMrzD2moXfU0U+Zr1jPjc+3hzTKNLxuKhAn5/1u+STM5A i1CHq2C2a1n+IQPrMa4pqmIPBALeKnq26C9gHIbOKlJBnG26/Rsk2muNremXRyU0G0 rZ6O3X4t6UMRLo2RDjcO3M62eRHBeufOiMR1k67wqprT0+vg2LrkMsaegFsk+L3M0P CwJJ7oFpdMLzSDe4JO/Dd+xIoUHOd0CBpHc+qPLP30Yq9YveMZRa9On/CU9zn0jZvO LDaFKZtwuB9yw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 376DE18054B for ; Wed, 10 Jul 2024 22:17:03 +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-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 22:17:02 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2c7fa0c9a8cso225863a91.1 for ; Wed, 10 Jul 2024 15:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720649736; x=1721254536; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JZppGW1dt4K1lWcgLiznCCAdz1cnAQJQU512CsMI77U=; b=cU8A5fjBucAo55+YYG7zF8b1475FCjB94XFzWhZluLaC6XZ6rdMDpadlGJk1BlH9en eGAAFdHLaMKpSfVW6b5EH5N2o9yJVAsQAd8dr8oStkX3LUkfdbztbh3atsNgqxxbqiIQ 4jXLSrkl4UFGwCY+eKjhgvAIXxOTn3oiNaL0qvKZfWYzI1XP4d7EnghrBl8hiBVc5tN/ vyoumX3wlxu26m4ZZXsunefU2z7DpHbJet/a/8eJFAbnQwigtXnElizQFN/jWaPQuM9D JdKEN/hLCaM1E2OhaiVNVS7ZbXW8OilAWJyCpm/l+XUOwAA6GLPANC2XF0b5fq09LlVa EkKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720649736; x=1721254536; h=cc: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=JZppGW1dt4K1lWcgLiznCCAdz1cnAQJQU512CsMI77U=; b=pJ6FzklqGyBnUmFPzbkcOV71ITcDvgB54ptQQZ61ZcllVqD8dtV4QnNJOwXnjOfsgm +8Cl6iFpMnU2Met0u3Z7AoCkwrZDaDo/PLLFHt17FvzK6TFWhT19N7vEE9t7VWQ3Ovuj geAdxM+h4eYxG1OS0riEVvovwkOXe2/s5CsviDYfRtNHzrKjIWq1zV0NI4L8UKVbk2hf 0wpoBm5YiasRylgWpu8XGdI8js4k94pmtdsEB+5G00D76ZA7RvRYM6sQ+GM7Djg6fYda WNqOS1ra697fAGbh8zAfatCF5DOiBDDA6rIvnNgZzK9uevYoPSXd8aUetqQJnsYaYJJr Zdgw== X-Gm-Message-State: AOJu0YxHjbqlSjyfH1Uz7DFDt9qTSWcCWnBx4RumHD5AzzANTINmqEb+ wfALQUIFVJDutxjvAUnJaKmj1616pKnFMmlJ37CPXH/E7pqn4kyHGwyLQSAezHvnfXKSpYozRRe EGdlVW/5lIaszyMI1EqihKaP2t48nLe7T X-Google-Smtp-Source: AGHT+IEGkMX9jt/hAKDBOpsA6/OgHb6gaYXUQYOI2t1otvHwPTxVPnAV8V8bek7ldZ5aJh4bplngMuKNKlhMuZ3zxjA= X-Received: by 2002:a17:90a:c097:b0:2c9:6cf4:8453 with SMTP id 98e67ed59e1d1-2ca35d392e0mr5699748a91.31.1720649735480; Wed, 10 Jul 2024 15:15:35 -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: Date: Wed, 10 Jul 2024 15:15:23 -0700 Message-ID: Subject: Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV) To: Michael Morris Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000442d8e061cebfc0b" From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000442d8e061cebfc0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2024 at 1:08=E2=80=AFPM Michael Morris = wrote: > > > I'm in no rush - though it might not seem that way. I don't see this bein= g > 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, bu= t > 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 i= s. > The point of people asking multiple times to wait until any other time of year is not because anyone is worried you are trying to get it in right away, it's because doing this kind of freeform "I don't know what I don't know" discussion is unkind to all of the experts on the list who CAN tell you "well, what you don't know is X". Most of them probably won't even respond at this time of year, even if they did read, which they probably didn't. > > >> >> >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 wa= nt. >> >> >> > 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 d= o > need a list of these things we'd love to do but can't because of reasons. > > That's your job as the proposer. :) > >> >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'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 talk abou= t >> 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. > Try to change something, compile, then debug a test file with it. That's how I went from "has only done basic C" to "wrote almost all of the implementation of operator overloads" in a few months. Once you start on that, you'll be able to ask more specific questions that are more likely to get a specific and quick response. You'll want to know "when do we use this macro" and so on. You can also reference all the documentation that has been built for people who are getting into learning the PHP source: https://www.phpinternalsbook.com/index.html > >> > Existing code >> >can be loaded into packages, but also an outline for writing packages >> that >> >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 other >> changes; existing code using /** @internal */ should ideally need minima= l >> 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 o= f > 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. > So then the purpose of modules, to you, is explicitly to provide features that "can't be done" in PHP? Most of the ones people want are being worked on in some way, even if they "can't be done", so I'm curious what sort of list of features you'll come up with. That feels like it lacks the defining and critical feature of packages and modules in literally every language that has ever had it though: Encapsulation/Restricted Global Scope/Local Symbols If "modules" are not somehow separated in a controllable way, then you aren't building "modules", you're forking PHP. Jordan --000000000000442d8e061cebfc0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 10, 2024 at 1:08=E2=80=AF= PM Michael Morris <tendoaki@gmail.= com> wrote:

<= div>
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=C2= =A0been discussed before, but they peter out. If they are to be solved some= amount of=C2=A0stupid bulldog tenacity will be needed. I think I'm stu= pid enough to provide that, but I need to do it without being annoying.=C2= =A0=C2=A0

In any event these threads have already = shown me a great deal of what I need to learn in order to get to an effecti= ve final form, whatever that is.

The point of people asking multiple times to wait until any other t= ime of year is not because anyone is worried you are trying to get it in ri= ght away, it's because doing this kind of freeform "I don't kn= ow what I don't know" discussion is unkind to all of the experts o= n the list who CAN tell you "well, what you don't know is X".= Most of them probably won't even respond at this time of year, even if= they did read, which they probably didn't.
=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
=
That's your job as the proposer. :)
=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.

Try to change something, compile, then debug a test f= ile with it. That's how I went from "has only done basic C" t= o "wrote almost all of the implementation of operator overloads" = in a few months. Once you start on that, you'll be able to ask more spe= cific questions that are more likely to get a specific and quick response. = You'll want to know "when do we use this macro" and so on.

You can also reference all the documentation that ha= s been built for people who are getting into learning the PHP source:
=

=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.

So then the purpose of modules, to you, is explicitly to provide features = that "can't be done" in PHP? Most of the ones people want are= being worked on in some way, even if they "can't be done", s= o I'm curious what sort of list of features you'll come up with. Th= at feels like it lacks the defining and critical feature of packages and mo= dules in literally every language that has ever had it though:

Encapsulation/Restricted Global Scope/Local Symbols
If "modules" are not somehow separated in a controlla= ble way, then you aren't building "modules", you're forki= ng PHP.

Jordan
--000000000000442d8e061cebfc0b--