Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126810
Content-Type: multipart/alternative;
 boundary="------------WbsUQY29zOp7Z7MLi2uLluuI"
Message-ID:
 <AM8P250MB0170DE2A7E1AEE1FE1ED1F7CE2DF2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Mon, 17 Mar 2025 19:05:49 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC: short and inner classes
To: Rob Landers <rob@bottled.codes>, fennic log <fenniclog@gmail.com>
Cc: internals@lists.php.net
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAO__Xv4END_NsATOGSnCArGuP_UmSpMxSMsSNPsQZnLooOWTsQ@mail.gmail.com>
 <3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|AS1P250MB0631:EE_
X-MS-Office365-Filtering-Correlation-Id: 7334f4e8-4cfc-4962-5e6f-08dd657e5992
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|12121999004|461199028|19110799003|8060799006|5072599009|7092599003|15080799006|19061999003|3412199025|440099028|12091999003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?REJ3YWpteDZHanRoamFQcDY0NWVheTR3MzExY3gwczg5V3JhTXZJUWF3aTU2?=
 =?utf-8?B?UTMyVFpuZzEvbEpSc05ldW9vbVBuZjBPSGZnWW5lOU9PS2VONUYyRUJ6dmg5?=
 =?utf-8?B?WHVhL3JTTnpVTDVpdU15RmJtcVYyMFVnSTFER1pHU1RpcUV3VW9BRkVUWjJ2?=
 =?utf-8?B?T3NjMnEwclU1VUs4ek5KVTcrQ0NGQ2E2Y0VMeFFCeWNnQ0JGTnh3dDIrRDRp?=
 =?utf-8?B?djh5MW9zV1YrSCs5MVlyaHFlVEsrcnpmMTdFY3phbzJzNllrSFNpdklxejJ5?=
 =?utf-8?B?SSs3bkZncXpHeHEyeEZXMHRKbUFiM1BSZHBPNGlrcW41TEVUVEdkZU9jOTdL?=
 =?utf-8?B?dGEreDBScUhFcEhJVlBqNVRLTGRSSEIyendJYVl5NHZqalhid00wU0luMzRG?=
 =?utf-8?B?WHlpenNKVHlubnVyUUh1cVJkcVY4ekpBd1hod3NVZVNqRHpsU09Md1dNZm85?=
 =?utf-8?B?MTc5eTd1R2Q0elpxbUQ0dUFXQktxbHp6TEQyV3pLdmJnUjhoSGZGWWM1ZGVR?=
 =?utf-8?B?MDB3TWxQbXBwLzdEY05TZXVWZ01MMUszYThtSTlZcEVFTVJkQnl4YkkzWWUv?=
 =?utf-8?B?UTUrRGJwSFA0ZnYvYVp5RiszcjVJaEIwakJsNlFJWXl3cjFaRTE5VU5vYnBu?=
 =?utf-8?B?aGRlS2pTV2VyWlFKZHVuZWZFTXRlYVQ3L3p6Z3VUOTNuRUhLeVpENzVGLzds?=
 =?utf-8?B?cWxFNkRKWStCYzhFUis3TXJxUjFCT3MxcWJ1VWNYenBwR2tGWitsbVR6ZzZu?=
 =?utf-8?B?QzZyRnBYSkRNbFJYSHlRV0thRlRJeG93NXRYenRPVE9MWkxxMCtUTnRhL3hX?=
 =?utf-8?B?d21nVzBlMEdaTnFNUVM1bHl5VW5iaW0rajViQVJoa2R4MXFWS3plYlFxUEY3?=
 =?utf-8?B?RUlMaHRBcTl1aWVRNHpOd2VkVkRtNVJqd3ZCNWJnUlJRTFJhc0FHaS9mdTkw?=
 =?utf-8?B?a1VQUzkzcVhtSGt4UnRoU1pLcVp4WFRPLzdyano1Mmc4L2tkazBUaCtiUUdB?=
 =?utf-8?B?RFlzUWhqaHQxbldtcnRBaEFycnVuNTZiSnB1RVFSY2oyZ1F5clZSWnc5MUNn?=
 =?utf-8?B?aVhPbk44Q1N5UGR1M082OEpQeUptTlNhRG82Qi81SXVXaDlhWWsra1VZZ2NX?=
 =?utf-8?B?ajZhQlRkU0pVTnNOUFM3T1BCRVFIR0lQSzh3S05wT1E4djIrTDAxUDBvWlhK?=
 =?utf-8?B?K05FYUQ4cm1mWkJoV2NZcmJ3NTRJaEc0aE9EaS9ONittUXN1TkRuVytaK2wv?=
 =?utf-8?B?bGdrVGZ2VHA2Q094UTN5QkF5Y2t5Q3RYTEhScDhsQldERkxITzZxNjlmdUJW?=
 =?utf-8?B?V2dHaUM2MHNoL0M2ZzNYbnlZNGFUbmVKTUV3bUc0bXpESitmcE9IT2ErejhO?=
 =?utf-8?B?cGQ5YzRrMXFjeFJIU0dKTXBGVEw1M0cwTlZ6Y0lsVjljK0QyN0d0ZkxaVEdI?=
 =?utf-8?B?aWhqWm5mUU03Z0Z6a2FuMDhaUVpxTGVRTG5DYnlXYUNFb0srM1hvcFRrRk55?=
 =?utf-8?B?YXpJY2t6Vm1vSmtIM00raWtjSkZaOGJCcEpOaUIvWVpyMDZOY0h6ZjR4YXpC?=
 =?utf-8?B?dkxEMS83U3ZkVVgyTVRmcEFaT2E2STEzRW8xb1NTdTAySGZnc1JFd0hieVQ0?=
 =?utf-8?B?Q083YWhlaWFjVVJINmM5WE9nZ3IwaFE9PQ==?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bFhPcTNzc1VFS1VqN0h2MjRVZUtEck1zTTRUREJoK3JSSE5KV2hJaHR1eGx1?=
 =?utf-8?B?NjREbFpVdFcveVRmWThqSEFPUDJkL2VhTlhlK2R5bUlnUGZndSt1YlcyNkZi?=
 =?utf-8?B?TlRzZmYreGFhWUUzTGd5Q3hJa1EzOVBwSUFRWmdGQnBWUDlmejRNcE96blVG?=
 =?utf-8?B?ZVlEQjVoNG8rMkV2SEVqSk5rVUpLRkZRblErblBScEo1Y1FiYkVZRVhteU53?=
 =?utf-8?B?WVFCVXFMWDRwN3ZTRG0vMUZTYmxBV0hjNXFYUTI1QjFFczVYRm82M2JpUklK?=
 =?utf-8?B?S0FDbEpmeUhCbFJZbFhKbXlkcTFKcjJCOG1VdVRaMFRQaVRUbjBuaG9KMDgx?=
 =?utf-8?B?U2MySnNqUllubmVsRG8vSXk5RklBL0lSUDZta1ZvOXBWa2tHckluNmJjblJ1?=
 =?utf-8?B?MVdGQ2RISTRBbGdlV3ZQMWFvcy81M0pJNk1YY044RUZhdE9zenA3eXF4bStl?=
 =?utf-8?B?RTYrTXRXaStpTmJYeHBJd20yNU1QRXFJRzY2ZU5OTHpjelNzdkpPMm9DMEx4?=
 =?utf-8?B?Nm1WaHJSUE5jdVJPakJadVFFSlBGMU9ucW1XVDNEZFNzM1dRMGRzQ1dOSnR2?=
 =?utf-8?B?OGhSSUFIb3EwQ1R6YUNpejRENDlmZHhuN3h3TndyeU52QnBOc1JhM0x0QWtN?=
 =?utf-8?B?ZFVwRkZZN2hSbEhKOUN5Yk5DRUxkWExMMFZIQVRKbW8vTDFLSmdyUzJGYjg2?=
 =?utf-8?B?NXpKSE9XWGwyZVRLeHBQNjJmN0JUbXN2THVwZUtTQUVzMFFyT2l5NDQ3dFZS?=
 =?utf-8?B?ODZwSHJUQXFmZURTYlZFTG5OeVZabktEbkxqSFpFUnk0aGVKTXRLdHlNZzdU?=
 =?utf-8?B?ZWxVR0ZDRm50SCs5U2Q1RmJyZ1Job01hRlpKZjczUFpMNy8zUDhEUzc3cHpz?=
 =?utf-8?B?QW55bEVGNldCYVpncjBNOFltUmo5YW1scmZGSW85Sk5YbGgxQkNKTWRlWmp3?=
 =?utf-8?B?ck1XUUtJUmVBSFpOMFVFUzBCVnNMSE93TUZOV0dXN2hGZzBvYnYvZ1JNZXZF?=
 =?utf-8?B?bHVaQ3c2Wk5SZks3c3B4Sk15Z1l5dUZhRGlwOUgxd2JzRXhNbXRPbHN2elJD?=
 =?utf-8?B?cDdaU08yYi9JUHRhRC9sUytrM0VFQzBYSjNKU3MvbGlDdFBWUlRCbTRqV2t6?=
 =?utf-8?B?M0xSMzYyaG8zOWdNNnMwQnRoSHgvVXJlS3hUbXdHbVFvZ0R0M3BiekJyRXdL?=
 =?utf-8?B?TXJ3RnVCMlBHOG5LT1BKazNVOXNzZ2tkbGdnSGg0RXAwZzBQVUoxMytzTG1L?=
 =?utf-8?B?ZkVPVVB1di92QWxFU2RJbHpYcEcvTGQvVE9zZVZJdFdHa3N4eEN4QUtNSlcz?=
 =?utf-8?B?dlZxclFQb1crVU52L2dhZUNBbjlXMCtHY05LOTBzY21xL3dhRDV5RXVGV2Y3?=
 =?utf-8?B?aWs2cGoybm9xQ0VvaFlQWDRMclRCK3hNeWZvQ1dRYWl5MTVBYitzR3JMTUlH?=
 =?utf-8?B?NlJiL1lwYi9XdU9waFRFTGJVRFl1T0lvL2NzOC9lT0RXYkVmTG4wSWIzQmxz?=
 =?utf-8?B?N244U0FrMWxyMld4QkF3blEvVlovYmh2NEFZUUNLUG1HaW1peXIyVXlPNEd2?=
 =?utf-8?B?M01ycmRHdnQvK20wcXR1LzBTaEh1bkNWWUZycm95b1Z1aWlYU21mVEQ4cHNK?=
 =?utf-8?B?WkNKdXdUQTdMTGhrcHdId2NsODVDdnN2QmZEZno0ejlJR0hyWUM4Nkh3RzFE?=
 =?utf-8?B?Z1ZzdldDQ0VqWlc2azMwQU5YYVozZUFGejY2T09FRlN4bk1kWkdGVUppN0VN?=
 =?utf-8?Q?qo7NXbLg7m5XgIAkUM=3D?=
X-OriginatorOrg: sct-15-20-7784-11-msonline-outlook-95b76.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 7334f4e8-4cfc-4962-5e6f-08dd657e5992
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2025 18:05:50.3860
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1P250MB0631
From: bobwei9@hotmail.com (Bob Weinand)

--------------WbsUQY29zOp7Z7MLi2uLluuI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Rob,

On 17.3.2025 17:53:26, Rob Landers wrote:
> On Mon, Mar 17, 2025, at 16:30, fennic log wrote:
>> 2. As with any syntax change and new operator there needs to be very 
>> careful consideration, do we need a new operation, or could `::` if 
>> the parent is static or `->` if the class is initialized?
>
> There's quite a long thread already about this very topic. That being 
> said, the inner class has no bearing on whether the outer class is 
> instantiated or not. Originally, I used `::` as the separator, but it 
> seems there are some good arguments for `\`, so we will see.

I have not grasped any single argument in favour of \, except "other 
languages are doing it too", "existing tooling splitting on backslash 
would continue to work" and "we could use the existing use statement as is".

The problems are numerous though:
1. Unlike other languages (e.g. C# and java), namespaces and classes may 
share a name in PHP. E.g. class "Y" in a namespace "X" and class "X" may 
not exist both. In PHP that's allowed. Inner classes compete with 
namespaced classes for their fully qualified name.
2. Autoloading will have to become aware of inner classes.
3. Autoloading will have to do a non-cacheable check for existence on 
the inner class, before iteratively testing whether any parent has a 
respective .php file. Currently autoloading takes a class name, 
transforms it to a single canonical path, and includes it. Always 
succeeding.
4. Humans, navigating to a path, will not be able to navigate to a file 
directly but have to search for it.
5. Tooling splitting on backslash might assume the 1:1 mapping to the 
filesystem and break. It's really not a catch all. Some things may be 
broken and some not, but all need to be probably revisited anyway.
6. It makes accessing via parent, self or static weird. These keywords 
have always been followed by a double colon. (Even if this particular 
RFC does not end up adding them) And it will conflict with a namespace 
named "parent" for example.
7. At least right now, every backslash identified symbol is trivially 
universally public. With \ as an inner class separator, this would no 
longer be the case. Maybe that will eventually change, but today this 
can be relied upon.

Also, just because other languages are doing a mistake, it does not mean 
we have to repeat it. They are generally doing it because their 
identifier separator is universal and it's consistent. It does not mean 
that it's without its own problems.

Using the double colon is a very minor BC break (accessing a class by a 
class constant value?! That's also quite inconsistent that it works at 
all, as you can't do that with normal constants, only class constants.).
Using another sigil would also be possible (like :>). But for the 
backslash I only see drawbacks.

Also, nothing precludes us from allowing "use Foo\Bar::Inner;".

>> 3. The idea that extending the parent class doesnt no inherit the 
>> child classes doesnt make sense to me.
>> As then if you extend a parent class and call a function of that 
>> class which could rely on the existence of an inner class, I can see 
>> a lot of headaches caused by this exact scenario.
>> As a developer, if I extend a class, I expect the entire dependance 
>> of that class to be inherited, otherwise the extending class won't work.
>
> I'm not sure what you mean. When you inherit a class, you do not 
> necessarily inherit everything from its superclass. You are free to 
> override it however you want. Since we are defining "types" in the 
> sense of PHP, we cannot merely inherit a "type", otherwise we would 
> cause all kinds of issues with LSP. This is specifically why 
> inheritance works the way it does in this RFC and why `static::` is 
> forbidden.

I don't understand the problem here.

for each nested class in parent class:
     class_alias(substitute parent class with child class in class name, 
class name)

Very simple. There's no magic needed, it can be simply class aliases. 
This will also make static, self and parent trivially work.


On 15.3.2025 00:37:08, Rob Landers wrote:

> Classes don't actually know their inner classes -- they aren't like 
> properties. In essence, an inner class is just a regular class with a 
> funny name and access to scopes it wouldn't normally have access to. 
> We could probably add `getOuterClass(): string` if that is useful. It 
> is possible to keep track of a class's inner classes, but then that 
> introduces a paradox chicken/egg type problem during construction, 
> which may or may not be a problem.
>
I don't see the chicken-and-egg problem here. You can simply collect all 
the inner class names at compilation. You don't even need to actually 
store the zend_class_entry - just collect the names and fetch from the 
class table at runtime (and ignore missing ones, e.g. if there was an 
error during linking).

--------------WbsUQY29zOp7Z7MLi2uLluuI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hey Rob,</p>
    <div class="moz-cite-prefix">On 17.3.2025 17:53:26, Rob Landers
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com">
      
      <title></title>
      <style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
      <div>On Mon, Mar 17, 2025, at 16:30, fennic log wrote:<br>
      </div>
      <blockquote type="cite" id="qt" style="">
        <div dir="ltr">
          <div class="qt-gmail_quote qt-gmail_quote_container">
            <div>2. As with any syntax change and new operator there
              needs to be very careful consideration, do we need a new
              operation, or could `::` if the parent is static or
              `-&gt;` if the class is initialized?<br>
            </div>
          </div>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>There's quite a long thread already about this very topic.
        That being said, the inner class has no bearing on whether the
        outer class is instantiated or not. Originally, I used `::` as
        the separator, but it seems there are some good arguments for
        `\`, so we will see.</div>
    </blockquote>
    <p>I have not grasped any single argument in favour of \, except
      &quot;other languages are doing it too&quot;, &quot;existing tooling splitting on
      backslash would continue to work&quot; and &quot;we could use the existing
      use statement as is&quot;.</p>
    <p>The problems are numerous though:<br>
      1. Unlike other languages (e.g. C# and java), namespaces and
      classes may share a name in PHP. E.g. class &quot;Y&quot; in a namespace &quot;X&quot;
      and class &quot;X&quot; may not exist both. In PHP that's allowed. Inner
      classes compete with namespaced classes for their fully qualified
      name.<br>
      2. Autoloading will have to become aware of inner classes.<br>
      3. Autoloading will have to do a non-cacheable check for existence
      on the inner class, before iteratively testing whether any parent
      has a respective .php file. Currently autoloading takes a class
      name, transforms it to a single canonical path, and includes it.
      Always succeeding.<br>
      4. Humans, navigating to a path, will not be able to navigate to a
      file directly but have to search for it.<br>
      5. Tooling splitting on backslash might assume the 1:1 mapping to
      the filesystem and break. It's really not a catch all. Some things
      may be broken and some not, but all need to be probably revisited
      anyway.<br>
      6. It makes accessing via parent, self or static weird. These
      keywords have always been followed by a double colon. (Even if
      this particular RFC does not end up adding them) And it will
      conflict with a namespace named &quot;parent&quot; for example.<br>
      7. At least right now, every backslash identified symbol is
      trivially universally public. With \ as an inner class separator,
      this would no longer be the case. Maybe that will eventually
      change, but today this can be relied upon.<br>
    </p>
    <p>Also, just because other languages are doing a mistake, it does
      not mean we have to repeat it. They are generally doing it because
      their identifier separator is universal and it's consistent. It
      does not mean that it's without its own problems.<br>
    </p>
    <p>Using the double colon is a very minor BC break (accessing a
      class by a class constant value?! That's also quite inconsistent
      that it works at all, as you can't do that with normal constants,
      only class constants.).<br>
      Using another sigil would also be possible (like :&gt;). But for
      the backslash I only see drawbacks.</p>
    <p>Also, nothing precludes us from allowing &quot;use Foo\Bar::Inner;&quot;.<br>
    </p>
    <p></p>
    <blockquote type="cite" cite="mid:3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com">
      <blockquote type="cite" id="qt" style="">
        <div dir="ltr">
          <div class="qt-gmail_quote qt-gmail_quote_container">
            <div>3. The idea that extending the parent class doesnt no
              inherit the child classes doesnt&nbsp;make sense to me.&nbsp;<br>
            </div>
            <div>As then if you extend a parent class and call a
              function of that class which could rely on the existence
              of an inner class, I can see a lot of headaches caused by
              this exact scenario.<br>
            </div>
            <div>As a developer, if I extend a class, I expect the
              entire dependance of that class to be inherited, otherwise
              the extending class won't work.&nbsp;<br>
            </div>
          </div>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>I'm not sure what you mean. When you inherit a class, you do
        not necessarily inherit everything from its superclass. You are
        free to override it however you want. Since we are defining
        &quot;types&quot; in the sense of PHP, we cannot merely inherit a &quot;type&quot;,
        otherwise we would cause all kinds of issues with LSP. This is
        specifically why inheritance works the way it does in this RFC
        and why `static::` is forbidden.</div>
    </blockquote>
    <p>I don't understand the problem here.</p>
    <p>for each nested class in parent class:<br>
      &nbsp;&nbsp;&nbsp; class_alias(substitute parent class with child class in class
      name, class name)</p>
    <p>Very simple. There's no magic needed, it can be simply class
      aliases. This will also make static, self and parent trivially
      work.</p>
    <p><br>
    </p>
    <p>On 15.3.2025 00:37:08, Rob Landers wrote:</p>
    <p>
      <blockquote type="cite">
        <div>
          <p>Classes don't actually know their inner classes -- they
            aren't like properties. In essence, an inner class is just a
            regular class with a funny name and access to scopes it
            wouldn't normally have access to. We could probably add
            `getOuterClass(): string` if that is useful. It is possible
            to keep track of a class's inner classes, but then that
            introduces a paradox chicken/egg type problem during
            construction, which may or may not be a problem.</p>
        </div>
      </blockquote>
    </p>
    <p>I don't see the chicken-and-egg problem here. You can simply
      collect all the inner class names at compilation. You don't even
      need to actually store the zend_class_entry - just collect the
      names and fetch from the class table at runtime (and ignore
      missing ones, e.g. if there was an error during linking).<br>
    </p>
  </body>
</html>

--------------WbsUQY29zOp7Z7MLi2uLluuI--