Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126816
Content-Type: multipart/alternative;
 boundary="------------Cpw6FbLBLalyfjJGGYQSw0Rx"
Message-ID:
 <DU2P250MB0176FD3F525DFCA32D5A55D6E2DE2@DU2P250MB0176.EURP250.PROD.OUTLOOK.COM>
Date: Tue, 18 Mar 2025 03:37:34 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC: short and inner classes
To: Rob Landers <rob@bottled.codes>
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>
 <AM8P250MB0170DE2A7E1AEE1FE1ED1F7CE2DF2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <782d76d9-711a-4cee-ae0e-fe0d69973f53@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <782d76d9-711a-4cee-ae0e-fe0d69973f53@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU2P250MB0176:EE_|DU2P250MB0222:EE_
X-MS-Office365-Filtering-Correlation-Id: 2ace4ddd-cdc4-456a-f028-08dd65c5d77e
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|5072599009|461199028|12121999004|8060799006|19110799003|15080799006|7092599003|19061999003|440099028|3412199025|12091999003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bm8rZlcvV0V3a0VVVXkxL1dZWFhrVWt5ZmRST0xubGQyelRHcnBwQUF0Z1pS?=
 =?utf-8?B?VWxTVk83dmxCWDM1SHgvd2djQWhaWHlrc0VNMTNsaHRTZ21uSk96SS9HN1Nk?=
 =?utf-8?B?RHBidk51SXkvUktTMXpQek92UGE1SDl0eVEwTFltR2lvYVJveElaVi8wNTQ1?=
 =?utf-8?B?OXZFSDVDR2JmYVlEdStrMjFjNU1ObkllSDA3S0tOWGlsL0d1cno2QXRzRlFw?=
 =?utf-8?B?Sk51dnk5a3RLU0xzSFBRWC9LQzh2bzhJT0VmRUZCamp2amdzZ0Z6UDhWdEFW?=
 =?utf-8?B?MEhOc2hCRzZobU85SVlrQlVzT3FWdWpkdjBLSkROdnh6N1NMTWZ2WWpURjE2?=
 =?utf-8?B?YzRaWkVDRlV1cWNzYzlaOFZNbGRCcEdRcjJQMit2THcySEJGck9WK2EzWndD?=
 =?utf-8?B?b1Iwc2RydUZqTDgzcEJpbkkwQklVNyswSSsxNmJROVNmS0p3cFBpVlFpcXFr?=
 =?utf-8?B?WlIzNDhsT0gvRWxDdzJWRnMvL2pqa1lscW15QTNlQ2FKcjlEM0hpbWl2dlFZ?=
 =?utf-8?B?VFhHV0Y4QitEdWVOL1NYOHJhMXpNYTFKWERjRkIxVm1ub0J6bXl1NktYUndX?=
 =?utf-8?B?aUxuYkNXdm5VUis5am9BdDVvcG9pSjdNdFFLNHlyRkpSMzZFMG9icXRtNjkv?=
 =?utf-8?B?VW8yWWVPb0Z2TzBvbCtCaU02U0s2Z05GMW9VZVErOC9NSXlpVlBrNnNkRzB3?=
 =?utf-8?B?UjVKUFpkeTV4clF4YmRFdlpZdkJvcVE1Tm15V2JrQWx0Q0Q0d0o5N2RqUm5p?=
 =?utf-8?B?NisrYmFhTHhsYm1za0Y4bkRINnA5aEVwVEM1QXUycmN6NDBNaWxONlZra1J0?=
 =?utf-8?B?YUVNVG00UCtUV09jeUZNcWl2RS96ZFNmLzFtSEdJcEpnSTlKUEp0YUxLcjVm?=
 =?utf-8?B?a1Bjc3RMUlRDWnNEL3ZlWlRRaUg4bml4YjFXSlAva3dqdUNRQWVpdHhtM0li?=
 =?utf-8?B?MzZlaTJQcFprRGRJa3doWTFGVmxjYTE4eWo1TC9rMERibmd4UzZVSHFNMGc0?=
 =?utf-8?B?Y3NOTHcyTzJOeWsyN1JuMDcyT3hHT0JoNmRaY1hBTHpMeTB6a21KeFc5MHlm?=
 =?utf-8?B?QzBSZzVpZHk2VGltZkd6TVREcCs2aHdDOHVqZGVqNnhkOXhpNWIzbUdWN2Y5?=
 =?utf-8?B?RUIwbEZrUFVnVUxrQlBXNWFjY05ZeC9WOUZock5sZDBXRDlSWk1KclhQU2lU?=
 =?utf-8?B?cWNmL1NiL0tDa1ROQXB1NzNiSnBsNDYxVjl5YnJPdG5IQUZRRXJZSGhlUDBR?=
 =?utf-8?B?RkhQVXhJMVIxdFVpUE0xM3ZHckdiSnNmMzg1OXl5SmpJdmtmSE9DbGxqWFov?=
 =?utf-8?B?QTNDQy9TNjlISkRRZVNwYUo0clYvcGNxREdublVGajZvSDFLSllDZitvWUYw?=
 =?utf-8?B?WkZlTzhyT2piRUp5SWJ2R2JyVEptcEZXc3JGeFdGZHdCd2MyWDlVNUN6OXZ6?=
 =?utf-8?B?U3c2elZVdUkyRTZWYVZ0WmpqUjRUVS80SHZqRkV4Y2xJWHZaTUcrZm5ZL1VW?=
 =?utf-8?B?T3hLYmJlRHJUV2UxOEZESTJOZ0Jjd0FKMGxsR0VqMjFGRTZqbXFLMzY2M0Fr?=
 =?utf-8?B?RGkwNTFkeVBSQXBBL0lFV2pTSGhmaGFBTWszNHk4V2ZvRkJnR3RXck42dm9Z?=
 =?utf-8?B?M2pOWjlmK1BSUHM0UHhqS1RzZUJEZkE9PQ==?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MHFzRkxTdFk2WnY1YzA2QUs5RHR2SjBJTjl3OEpBSEpjSTBJRnIxR3hGTE1m?=
 =?utf-8?B?OVZTUSt2dFByTXhSYUJoSHEvTWJ6aGtxQ28rWCtHU0xlRUtFekhWSkJRRWlM?=
 =?utf-8?B?aXgxV25yRTJuM0tWS3crdCtzdjl1ZzU0ZDJTOUExNlF2aTYwbEUrc1lGS1gv?=
 =?utf-8?B?QmRJbW1iYjhndnFoV3FrdkRlSWFFSk4wYXV5d202aDk0czFLVU1Gb1lmc0dW?=
 =?utf-8?B?MGVTdDdIeEc3QlpjNWttd3Q1a214QUN4UElTSTNWcm1VOXdOUjdjOXB2Sy9N?=
 =?utf-8?B?a0RBcTdCSDd1eCtJOStqaFNPZkU3SlFKQlZuYVBURmZOTHFCM2FwdWhrbElt?=
 =?utf-8?B?YmhNZGd2THpiVzh1amlVVjMyM1hHNG95QmthUjlOaEVzTU9ZemtPcjNoR0JX?=
 =?utf-8?B?WVVLNHVmdmZ1N1FhdGZPeFRwK0dmS21SSVRvclIyWGxLek8zSGFvanVaT2R2?=
 =?utf-8?B?OW9oakVqMjZoWG9Md01hM3J1a0ZYRDMyZ25jUk5WTlhxcUdTbWNLdVYrSU1y?=
 =?utf-8?B?ZEg3cHVkTHhWT2VueTJENytSMmNGbkw1RlRXOXUyZTkycGRoM0ZLdGt1bzJR?=
 =?utf-8?B?R2JHMVVMVWMwR0ZIRmZDUFpaTlBOYzBYc3BxZWV3SE9qeFYwMDBDQndjWFdn?=
 =?utf-8?B?RUNoSmlSZnplYmZFVENPcmVWL09tOWZSYzJQNnFIOVNSSWxnNWZIWHRyaUxa?=
 =?utf-8?B?U0lkVkJrWkFEN2Z3aC95ZUpGV0MxbGVuZGlCTW1pYmtmdmYwZWRwVHd3a0l6?=
 =?utf-8?B?Rk5DZ051REtuMDRHaDBhU0pVemx6dzZwUDlLZjMwd0pqR1BDMjdzTGlLUTlK?=
 =?utf-8?B?QXh2bElqREhWNWZzWGNEWFByb1pva2JISjJjTFdQck41N2JPL2FLUUQ3Tk96?=
 =?utf-8?B?QXhFK3BKdTRhQ1l3b0dVMWpUbTk5YnFxNFQrUVI4UjVxd09Sc01pdVZ6K3Nh?=
 =?utf-8?B?OGJVUHRTcHFEMTdTczkwS0RqL0hKdUxCSmY5a3pGQzYrOXFCWTRVRDFiTE9Y?=
 =?utf-8?B?MWV4MkxCSmNtMEsyN1NOYnpFUVdnTDh1U1RkVEoxVFlUY0lDVVY0cG1XU0VH?=
 =?utf-8?B?TFVWMnV1ZnBxbzdoTXpsRWI5YUlKMUNac0hXWG9mK2xYMzlFY0ptbmo1WGY4?=
 =?utf-8?B?T2RuNy9TNlRhaGRlZEc3bWJZc2Z1ZlhpMlgrUEZ5UWxDU1puTGUwKzhYY3JJ?=
 =?utf-8?B?VEUvaGpCWURBQ2lzSmxBSGhlb1hEM3ZRMWd3L2R1c1A1WjNNbkdEYU5jLzNv?=
 =?utf-8?B?d2QwbUEwOUF4QVZpMklGamF3ZXdaNWFldWtnWjhtWjdCNmw0bkt5QTlvR29G?=
 =?utf-8?B?MjViMEdhek14OUl5ZGlXaWorbEh4cGx4RzdaYXIxRWlUZnZLRzJMTUF3RjNQ?=
 =?utf-8?B?TWFwTGRKVFlTZUFVTDlDS2pQY2dLdlp3Sks5U2hpYUFCMnhlL0F5Ri9zZGxl?=
 =?utf-8?B?Ums3ZjdLQzNkd3Ewczk3QjlFaFJUTG4xakhxWm1OZWJ0WVlmN1I5ckwvSHBD?=
 =?utf-8?B?emJ6REE3RUdjMUJ1dkVLS1dJdWg3UTVhL3ZBMGV0YjczMk50eWh4d21xTm1E?=
 =?utf-8?B?U3k2OVhFMENtZWVIcnhtRWp5M1lORjNhQlR0UVBLWGVoL2NYNTBFaDl2M0lp?=
 =?utf-8?B?ZUtvTWlMZWd5cC9zMWx3V3pkczJnaFM2ak5QTUJQdG5DeDhJYXNtRnFMaFJB?=
 =?utf-8?B?T3gwRVpUbTY3Q2hXOS9CTWM3OW9nSkNlTFJmMFRqSXE4UTNTYXBMUnY5Zmxm?=
 =?utf-8?Q?SoImLTJGXUv5xX85BY=3D?=
X-OriginatorOrg: sct-15-20-7784-11-msonline-outlook-95b76.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ace4ddd-cdc4-456a-f028-08dd65c5d77e
X-MS-Exchange-CrossTenant-AuthSource: DU2P250MB0176.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2025 02:37:36.1048
 (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: DU2P250MB0222
From: bobwei9@hotmail.com (Bob Weinand)

--------------Cpw6FbLBLalyfjJGGYQSw0Rx
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey,

On 17.3.2025 19:58:39, Rob Landers wrote:
> On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:
>>>> . 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.
>>
>
> PHP doesn't go out of its way to prevent the developer from violating 
> LSP -- but where it can, it does. If a type were inherited, then the 
> subclasses wouldn't be able to guarantee that an inner/nested class 
> implemented the parent inner/nested class. Or, if it did, it would 
> require that all subclasses using a class of the same name MUST 
> inherit from the parent class as well.
>
> This is non-trivial to implement as the parent class may or may not 
> have been compiled yet when we are compiling the subclass. So, we have 
> no idea what the parent class actually looks like until runtime. 
> Further, it is much simpler to reason about each class as a distinct 
> type vs. maybe inheriting a type from a supertype.
>
> Thus, if you want to inherit from the super-class's inner classes, you 
> can, but this RFC won't force you to do so. In my mind, this is the 
> biggest argument for a `\`, because the enclosing class acts more like 
> a namespace than a type, from the perspective of the inner class.
>
> If we were to embrace `\`, then it could be argued that a namespace is 
> technically a class in itself, (but a partial class, to borrow from C# 
> terminology) and every class in a namespace is essentially just a 
> public class in that super-class/namespace.
>
> Nobody has argued that perspective, but I believe it may be 
> interesting (and would lay a foundation for namespace private/public 
> class behavior/visibility). That being said, it truly does cause 
> issues with autoloading -- at least, PSR-4 autoloading -- and I'm not 
> sure whether we should solve that problem here; however, it is 
> something to be cognizant of, for sure. There are other types of 
> autoloading supported by tools, such as composer, that do not have any 
> issues with using `\` as a separator.

Okay, I see the point with LSP. I'm not sure whether we need to preserve 
LSP for that specific scenario, but neither can I say that we should 
ignore it.

(Effectively implementing LSP would mean that there's an implicit 
interface matching all public method signatures of the parent class, for 
child classes - which is doable, but possibly too much for the initial RFC.)

I would however ask, should we not implement LSP compatible inner 
classes, to enforce that no child class may name a class the same than 
any non-private inner class declared by any of its parents, until we 
resolve this question (in possibly a future version of PHP).
I do not think we should bar ourselves from allowing this in the future.

However nice grand unified naming schemes may seem, I don't think it's a 
good idea to pursue. Clarity and explicitness shall reign supreme here.
I also don't think that the proposed visibilities are applicable to 
namespaced classes. In particular and in practice shared internal 
classes are not necessarily directly organized in a way it makes sense 
to organize inner classes. Also visibilities like protected propagate 
along the inheritance chain, something which is not given with (outer) 
namespaced classes.
The less we mix these slightly different concepts, the better.

"It's similar, except in these and those cases" is the death of all 
consistent experiences. Thus, let's not even attempt to pretend it is.
And not pretending starts with using a different symbol than a backslash.


Bob

--------------Cpw6FbLBLalyfjJGGYQSw0Rx
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,<br>
    </p>
    <div class="moz-cite-prefix">On 17.3.2025 19:58:39, Rob Landers
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:782d76d9-711a-4cee-ae0e-fe0d69973f53@app.fastmail.com">
      
      <title></title>
      <style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
      <div>On Mon, Mar 17, 2025, at 19:05, Bob Weinand wrote:<br>
      </div>
      <blockquote type="cite" id="qt" style="">
        <blockquote type="cite" cite="mid:3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com">
          <blockquote type="cite" id="qt-qt" style="">
            <div dir="ltr">
              <div class="qt-qt-gmail_quote qt-qt-gmail_quote_container">
                <div>. 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.<br>
          </div>
        </blockquote>
        <p>I don't understand the problem here.<br>
        </p>
        <div>for each nested class in parent class:<br>
        </div>
        <div> &nbsp;&nbsp;&nbsp; class_alias(substitute parent class with child class
          in class name, class name)<br>
        </div>
        <p>Very simple. There's no magic needed, it can be simply class
          aliases. This will also make static, self and parent trivially
          work.<br>
        </p>
      </blockquote>
      <div><br>
      </div>
      <div>PHP doesn't go out of its way to prevent the developer from
        violating LSP -- but where it can, it does. If a type were
        inherited, then the subclasses wouldn't be able to guarantee
        that an inner/nested class implemented the parent inner/nested
        class. Or, if it did, it would require that all subclasses using
        a class of the same name MUST inherit from the parent class as
        well.<br>
      </div>
      <div><br>
      </div>
      <div>This is non-trivial to implement as the parent class may or
        may not have been compiled yet when we are compiling the
        subclass. So, we have no idea what the parent class actually
        looks like until runtime. Further, it is much simpler to reason
        about each class as a distinct type vs. maybe inheriting a type
        from a supertype.<br>
      </div>
      <div><br>
      </div>
      <div>Thus, if you want to inherit from the super-class's inner
        classes, you can, but this RFC won't force you to do so. In my
        mind, this is the biggest argument for a `\`, because the
        enclosing class acts more like a namespace than a type, from the
        perspective of the inner class.<br>
      </div>
      <div><br>
      </div>
      <div>If we were to embrace `\`, then it could be argued that a
        namespace is technically a class in itself, (but a partial
        class, to borrow from C# terminology) and every class in a
        namespace is essentially just a public class in that
        super-class/namespace.<br>
      </div>
      <div><br>
      </div>
      <div>Nobody has argued that perspective, but I believe it may be
        interesting (and would lay a foundation for namespace
        private/public class behavior/visibility). That being said, it
        truly does cause issues with autoloading -- at least, PSR-4
        autoloading -- and I'm not sure whether we should solve that
        problem here; however, it is something to be cognizant of, for
        sure. There are other types of autoloading supported by tools,
        such as composer, that do not have any issues with using `\` as
        a separator.</div>
    </blockquote>
    <p>Okay, I see the point with LSP. I'm not sure whether we need to
      preserve LSP for that specific scenario, but neither can I say
      that we should ignore it.</p>
    <p>(Effectively implementing LSP would mean that there's an implicit
      interface matching all public method signatures of the parent
      class, for child classes - which is doable, but possibly too much
      for the initial RFC.)<br>
    </p>
    <p>I would however ask, should we not implement LSP compatible inner
      classes, to enforce that no child class may name a class the same
      than any non-private inner class declared by any of its parents,
      until we resolve this question (in possibly a future version of
      PHP).<br>
      I do not think we should bar ourselves from allowing this in the
      future.</p>
    <p>However nice grand unified naming schemes may seem, I don't think
      it's a good idea to pursue. Clarity and explicitness shall reign
      supreme here.<br>
      I also don't think that the proposed visibilities are applicable
      to namespaced classes. In particular and in practice shared
      internal classes are not necessarily directly organized in a way
      it makes sense to organize inner classes. Also visibilities like
      protected propagate along the inheritance chain, something which
      is not given with (outer) namespaced classes.<br>
      The less we mix these slightly different concepts, the better.</p>
    <p>&quot;It's similar, except in these and those cases&quot; is the death of
      all consistent experiences. Thus, let's not even attempt to
      pretend it is.<br>
      And not pretending starts with using a different symbol than a
      backslash.</p>
    <p><br>
    </p>
    <p>Bob<br>
    </p>
  </body>
</html>

--------------Cpw6FbLBLalyfjJGGYQSw0Rx--