Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126743
Content-Type: multipart/alternative;
 boundary="------------yHQqLdxjYiSMQIPQbhxIX52t"
Message-ID:
 <AM8P250MB01707EFDB6113C6902884083E2D32@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Thu, 13 Mar 2025 23:26:57 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Re: RFC: short and inner classes
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net, =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com>
 <0d94bf183543ee9948fcd31337198438@bastelstu.be>
 <b10ba5b6-8427-4efd-b183-7902b349673f@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <b10ba5b6-8427-4efd-b183-7902b349673f@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|AS1P250MB0408:EE_
X-MS-Office365-Filtering-Correlation-Id: 7eb6f0d0-7db7-48ae-676d-08dd627e2af4
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|7092599003|15080799006|8060799006|12050799009|5072599009|8022599003|12121999004|461199028|9400799030|19110799003|1602099012|440099028|10035399004|19061999003|4302099013|3412199025|19111999003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?djc3MWZlSDBIU3FPZEVTbzdlQ3JvTkl1cUY0T3hiYTZRZzR5UENXdlBHSVBy?=
 =?utf-8?B?bE5NcHJ5WW80RXhyMC82MEJoYkRQeTN3WFo3UlpzV0E3OGdxMldoYkh5dlVQ?=
 =?utf-8?B?Y1dkNW1qTTRDckMyMzJpUEh2SWJZUFl1dWtnNGgveTdIbDZrbVJQU0crYnM2?=
 =?utf-8?B?Ty9SYzI2MU12MXZBUnVHemhXdk4vWVd0MkRCRm03UEtreVlSZkVROGZiVTc1?=
 =?utf-8?B?WXR2cVB1czZPaWlhdUtFMW1oaktxeHFmQUt5dG5JeEk2alFWS045c0d6VzhZ?=
 =?utf-8?B?QTlLT3FFL1lndVJjanNlcmM2N3NnRFlWZUlKVnR1bktNVUpmbkJEbVV1NmpS?=
 =?utf-8?B?cVVzYUcwTWg3ZE1aMkNDSXpwMk0yTlM4TndmbE43dVRpVis4T0NnL24zKzB0?=
 =?utf-8?B?V0xRbEtmOEZud1JVR3BPeFFVWW52cHVXM2oxV2R1dDdndjNCV2tVb01yd0FF?=
 =?utf-8?B?TEZ3RldwNEQzU0NDVXJETTNicFVUZEpZSFpoZ3IwQks4aHpiWHRMQmtRaFRW?=
 =?utf-8?B?ejN0UnlqN0ZDM28zTEgxTVZ0Yk1GSC81Y2wxV1ZKM3RwSzZOb3QrRzk4UFJn?=
 =?utf-8?B?eHUva2FaeTVzNEFSc3RmT3ltUE1zcEZCeGY4dzZROURuemdBZ1RXQzBveSs4?=
 =?utf-8?B?RTg0cEM3MlJqUEFjNExQbEtEVjdEbHB4QmU2bmVMbHk4c3lTNXVETDRwWkZr?=
 =?utf-8?B?REVGTlJOeE1SK2F5U0h3UTVQaS80M3I1eWU2RitxQjJZcFNkZEQ3M3ZaWkJS?=
 =?utf-8?B?RWs1WXlSdm12alVHeFpkR29CUm4yVEFUVkp3amVYWjFrTjFGVlZxUWM0Tkw1?=
 =?utf-8?B?TTBmODFrSHFjR0VxLytSekY5UVBmdWRIQmZ6Ymt5MGd3SXpxVElSbm9RY2M5?=
 =?utf-8?B?K09oTkFoNDBZOFZLaE5uMVRONWFrVmVJYVE2aGZINFl5UHV4alBuempTME1Q?=
 =?utf-8?B?NkJpRlRKQ2pGSWdBSUdmNGtoZTBFY3BQNmc3MytJY2JSNVdjcHJ4MC90TlNB?=
 =?utf-8?B?NVdpUTdIeEhlVjgvYVN3bWNhN2o3UDlWaWxldU1SZXNKa1ZhdGV4eTIranBB?=
 =?utf-8?B?YTVMN05oaVBISEt1NlZTNHc1QnFsTHNpakVPRjBjZmQ2YjhTRkVpV00razRQ?=
 =?utf-8?B?VzlKcTc2SHZGKzdaSGQrSDY3Q2tVYThwdWRZRm0xYUpqQ0tjNlZ0aTJ2Nksy?=
 =?utf-8?B?N0w4THQyazYyWHlkMVpxaGhWUDVwZEU4VUVUaUNuaDhrSEU0bmJycEdaeHVZ?=
 =?utf-8?B?MkVsTDlaQTlpV0JTMk4rTmZvNWlJWDNmQ29ZSWNHSnAxM1o2YUl5R04wRFZW?=
 =?utf-8?B?Qy81NWRud1hTT1hHcCs1aXZFdWJkRVdVdEZteVhHWDRsOVNDeUVWNys5VUxr?=
 =?utf-8?B?VEwzdlJUK2xvS0JQSE5kRVE3K1B4MGlQdDh3eWpFSFVDNVRqb1BRV3R0b2xN?=
 =?utf-8?B?WERKemhXWlZ6TEFFc3J6bnJvbEptTFFnYmJEUnluSVlWYnVJUjFlek96Y3Zo?=
 =?utf-8?B?Z1RKbWxMdG5uTEZNTUFFNXU4RzNPZGdsTnZMVWdPZXpYR2ROZHJISEJReGF2?=
 =?utf-8?B?YWozUXpxYloyUzJFeXJEb3grMkN6RFhjMXAzRUJQZndzMkNDS1Nqa3VnSFdi?=
 =?utf-8?B?eVF5TWlBZFRJZHNDQU5wQ1JmTC9JSWdQQ3kwcTF4NWJ3L3NjcjNySlg1MHZp?=
 =?utf-8?B?cHM5UVczMWM3SmduUXlFbjNqQVBuZmFCQ3IzMFRCeVhkYVdPcnZwTnNsVjZn?=
 =?utf-8?B?YkJpaWp5cW4rL2dOc0duSTZzbVYyV1ZNUUwyMVdKVks2L0pyQXpnVXdhdTFx?=
 =?utf-8?B?UEhCR0pyZVlndXlxUE82bEpMcDl6SzRjdDBnWlBPTUxVYzRsb3RuV1dXVERi?=
 =?utf-8?B?anl6R3VZalB2NDM1cVI4VHAzVVFuNHhYRk9nRi85VW5WT00vOWt4QU5JeGhy?=
 =?utf-8?Q?lojhDViwDpQ=3D?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VTlhU0h5SlhuN084R0hjbXJtSXpLem8vdWlOc0RLeUF4U3FUYU5SS1dsbXpn?=
 =?utf-8?B?MVZSVFZibktjdkNVWjd3U211blZyaFVBaXBGbGRhUjg2bEN0VFlRaW9VTzFL?=
 =?utf-8?B?L1p4WjJKZGhSeE52UzJsTUdQUmZSUE9OM3ZCQjZEWWl0aWpiT0huRG1WcTZ6?=
 =?utf-8?B?SllIcTlnU2pBQm1NWHBGNC9KNVRyaExQOXcxeXVTOW5vZEJiNHdncWJ6WmV3?=
 =?utf-8?B?dzM3TFJPUTlKWGgwT0RvaUNIVE5tbG8xcU5kMUJVTktjYVNiQUFoQzJnUXRq?=
 =?utf-8?B?MitoMFB1WlBwRFBzd0FVendrV0JKa2I4bkV0RHFsVzBZdGlOTWprM3c0U0RD?=
 =?utf-8?B?cnM2WE1rcEtFbnVVYkFZQTNnekIwaXk5UUtDOExmWXhzZHVUZ212N3hDZjRr?=
 =?utf-8?B?SHFaVzlLUGlKQ3FndlVuYWl3Zm5kSTF4dUpnMWJxeTMvL29OdVFCRjNYS1lk?=
 =?utf-8?B?aXUxT1JaMThKY3I4U041T0RkbHJZdVduOXBxRmFua3ZJVGZlSFl1NTE2VVUr?=
 =?utf-8?B?ZHNtZmlkdm5kMlErbmRPUFlUdnRYOGRvYVc0QVBHUU1PU0xLWXB4aXRrNTBF?=
 =?utf-8?B?bmdaMnVpUEd2TlJtQ3JQZ0FINWdlbGZZalNGUWtxK0JlbVVacjZWRXczV1JK?=
 =?utf-8?B?VVFQOG1jMlpZdWVzWi84U2tFMDBTbnNQb01LWXlUMUpBTURGbzBzZ3o1cnJz?=
 =?utf-8?B?aEhoUVVaYS9mejlTSmFmdzV3cnJVLzVSUjExZGwzRXpkNGllbFhyRlErdjJ6?=
 =?utf-8?B?dHVscGMzekxyU2xDU1ZFOFQweEhEdzliazA1MU9GY1dseUcybzJGNjF0NXEv?=
 =?utf-8?B?WHNpbHdLbnYyYldMd2ZabEJ3d3BvblRtbW1paFBrYWxNdDBBWmU5cUU5T2RY?=
 =?utf-8?B?ZHN1UFc2V2t0V3FTT29tdlBKcFRlNlNmTFZHMU5HYTdsVGJ0Q1lCQUt4ZE50?=
 =?utf-8?B?cmtsSnFQS0wvTzlwSDBsQklLcHMrQ1ZWSytWdW1wQ0lla3dGYmFPcFRHTzB0?=
 =?utf-8?B?YURPdHhSMVRoWDBiRlpVN1FZYURTL2FxSkhnSmFQOU95WkRoVHVsbTdIZHVB?=
 =?utf-8?B?L3VUejNYU3lhLzdWVVM0VlZwc1lFdURQSDdkNUlnTm1yQ2RLWkQ4YjNJWGo1?=
 =?utf-8?B?TXd3b0tnS2Z2SDQvTkN1YUNJenpKcmZSc0toUGNia3ZIY1NtQlFNRVdSRkxN?=
 =?utf-8?B?bStCTk1LUGlsNzFCQnZvUTUrUkp0cHZnUjdQZEVyTXV0MGtQZ25Td1BsclVw?=
 =?utf-8?B?OS9uNGRxNEszanVUL1dqNXJ0WS9HTS9rZVdncXdsSmdabU51bjBxS0RmQ21H?=
 =?utf-8?B?T3Eza3lYM01kbjBqVVFPb2xoYkxGOTg4N1JQK0hkZ0JBVUdURDZLTFF6T1A3?=
 =?utf-8?B?bTdQL1dJeHNUUy9aMEZxQlg3bkNtMlU5RVByOC9IVEx2b2o0ZEFaM25xMkRU?=
 =?utf-8?B?eW5UdGROOCtDTERMaHJ3ZEl6Rnl0d3I1dUdJd0ZGNkNVRlhERnlWdGl1WUR0?=
 =?utf-8?B?ZHhwUmtzeEY0QU9aTnd5U1d1OWpaV204aHFQQ3J3M1Bqb2lacy9GNUJTZWFp?=
 =?utf-8?B?YUltdTYxcTZHcnBXNit4MjBGV3c2R2RYR0U4UFFBSTgzVndoQzd5MHhOUzdk?=
 =?utf-8?B?RDFLcUt6bWhWNmg0WVBzQUNzem90MWR3NlF6bVI3NHBFYXlxK2puckVoaC9t?=
 =?utf-8?B?ZVVRazN6L1FWQkpPd0YybHNuVkdxM3hsRnBnaUtZczQ5YlpWSS95VXJyMlZX?=
 =?utf-8?Q?233KnQk52I20zrYo0Q=3D?=
X-OriginatorOrg: sct-15-20-7784-11-msonline-outlook-95b76.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 7eb6f0d0-7db7-48ae-676d-08dd627e2af4
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2025 22:26:58.7578
 (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: AS1P250MB0408
From: bobwei9@hotmail.com (Bob Weinand)

--------------yHQqLdxjYiSMQIPQbhxIX52t
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Rob,

On 13.3.2025 21:46:49, Rob Landers wrote:
> On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote:
>> Hi
>>
>> Am 2025-03-12 11:10, schrieb Rob Landers:
>> > - Accessing inner classes is done via a new token: ":>" instead of
>> > "::".
>>
>> I don't particularly like that. It is “invented syntax” and I don't
>> think that inner classes are sufficiently valuable to dedicate an entire
>> operator to them that could serve a more useful purpose in the future.
>> It also got 4 negative points in the rating back when the namespace
>> separator was decided: https://wiki.php.net/rfc/namespaceseparator
>>
>> Would `\\` (i.e. two backslashes) work? The outer class for inner
>> classes effectively act as a namespace, so it makes sense to me to use
>> syntax that is similar to namespaces.
>>
>> I'll look into the rest when there is a new implementation, since I
>> assume some details will still be clarified and fixed as part of
>> implementing the proposal.
>>
>> Best regards
>> Tim Düsterhus
>>
>
> I am not particularly attached to the separator. I specifically chose 
> it due to being a mixture of :: and -> and -: seemed like a bad idea. 
> In other words, an inner class felt natural to use :> -- however, I 
> have some issues with it myself. Particularly, it is too much like |> 
> and as shown in the namespace RFC, way too easy to typo. Personally, 
> after using it for a few days, I'd almost rather go back to :: ...
>
> I will give \\ a try, but it has to be typed quite a bit when 
> referencing inner classes, so keeping it easy to type is a must. I 
> feel like \\ requires a large movement to type, at least on a qwerty 
> non-english keyboard. Maybe people using other keyboards can chime in.

Please go back to ::. The double colon was perfectly fine, the only 
thing which was weird was the implicit constant. It's fine for constants 
and inner classes to share the same name scoping (i.e. a constant must 
not share a name with an inner class). But an inner class should not be 
an actual constant.

But otherwise, this was perfectly fine.

>> I don't think that inner classes are sufficiently valuable
>
> I'm curious why some people feel this way and why some other people 
> are saying the opposite (emphatically). I'll nudge the private emails 
> I've received to speak up publicly on the list as well. But, why do 
> you feel this way?

I don't know why some people feel this way, but at least with the 
autoloading mechanisms we have in PHP there are definite limitations to 
multiple classes in one file:
- If you deserialize your data structure and it contains another class, 
whose name does not match the file name, you better hope to god that it 
has been autoloaded already. Surprising failures in production follow. 
(e.g.: the amphp\parallel process runner will try to serialize your 
exception. That's fine. But as soon as it's accidentally bubbling up and 
as it's not autoloadable, the hell breaks loose.)
- Enums or Data Transfer objects specific to one or multiple functions 
of only this specific class would naturally fit into the same file. But 
you can't do it ... because the autoloading might try to load the enum 
first, before the class whose constructor or function you want to call 
is actually loaded.
- Now, if you actually stuff multiple classes / enums into a single 
file, it's non-trivial to figure out (as the human reader, but obviously 
for the autoloader too) which file to access to read up the definition 
of a specific enum (short of using dedicated tooling for it).

Certainly, one may say - yeah, just religiously use different files for 
... every ... single ... class.
But what's the point of that dogma?
It definitely doesn't help the organization of dedicated helper 
structures tied to a single class.
It's a tool for organization. It's not complex to understand.

Outside of very puristic arguments I don't see any reason why one would 
not want inner classes.

Further, with short classes, should they hopefully be introduced as 
well, it will become trivial to write shapes for any internal 
datastructures - simply using a "class Point(int $x, int $y); private 
Point $pos;" rather than "/** @var list{int, int} */ private array $pos;".
This will be a very ergonomic way to reduce ad-hoc arrays which are only 
typehinted by phpdoc, giving proper typing and also safe access to 
structures via named accessors rather than [0] and [1] etc.

Further Questions on the (original) RFC:

- Why is there a conflict in static properties and the inner class name? 
The former always has a leading $ sigil.

- Any particular reason to disallow abstract inner classes? Feels arbitrary.


And a note: I consider the inheritance example misguided as "static 
constructors" (static methods which invoke new()) would be a better 
pattern here. Could you maybe come up with another example here?


Bob

--------------yHQqLdxjYiSMQIPQbhxIX52t
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,<br>
    </p>
    <div class="moz-cite-prefix">On 13.3.2025 21:46:49, Rob Landers
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:b10ba5b6-8427-4efd-b183-7902b349673f@app.fastmail.com">
      
      <title></title>
      <style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
      <div>On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote:<br>
      </div>
      <blockquote type="cite" id="qt" style="">
        <div>Hi<br>
        </div>
        <div><br>
        </div>
        <div>Am 2025-03-12 11:10, schrieb Rob Landers:<br>
        </div>
        <div>&gt; - Accessing inner classes is done via a new token:
          &quot;:&gt;&quot; instead of&nbsp;<br>
        </div>
        <div>&gt; &quot;::&quot;.<br>
        </div>
        <div><br>
        </div>
        <div>I don't particularly like that. It is “invented syntax” and
          I don't&nbsp;<br>
        </div>
        <div>think that inner classes are sufficiently valuable to
          dedicate an entire&nbsp;<br>
        </div>
        <div>operator to them that could serve a more useful purpose in
          the future.&nbsp;<br>
        </div>
        <div>It also got 4 negative points in the rating back when the
          namespace&nbsp;<br>
        </div>
        <div>separator was decided:&nbsp;<a href="https://wiki.php.net/rfc/namespaceseparator" moz-do-not-send="true" class="moz-txt-link-freetext">https://wiki.php.net/rfc/namespaceseparator</a><br>
        </div>
        <div><br>
        </div>
        <div>Would `\\` (i.e. two backslashes) work? The outer class for
          inner&nbsp;<br>
        </div>
        <div>classes effectively act as a namespace, so it makes sense
          to me to use&nbsp;<br>
        </div>
        <div>syntax that is similar to namespaces.<br>
        </div>
        <div><br>
        </div>
        <div>I'll look into the rest when there is a new implementation,
          since I&nbsp;<br>
        </div>
        <div>assume some details will still be clarified and fixed as
          part of&nbsp;<br>
        </div>
        <div>implementing the proposal.<br>
        </div>
        <div><br>
        </div>
        <div>Best regards<br>
        </div>
        <div>Tim Düsterhus<br>
        </div>
        <div><br>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>I am not particularly attached to the separator. I
        specifically chose it due to being a mixture of :: and -&gt; and
        -: seemed like a bad idea. In other words, an inner class felt
        natural to use :&gt; -- however, I have some issues with it
        myself. Particularly, it is too much like |&gt; and as shown in
        the namespace RFC, way too easy to typo. Personally, after using
        it for a few days, I'd almost rather go back to :: ...<br>
      </div>
      <div><br>
      </div>
      <div>I will give \\ a try, but it has to be typed quite a bit when
        referencing inner classes, so keeping it easy to type is a must.
        I feel like \\ requires a large movement to type, at least on a
        qwerty non-english keyboard. Maybe people using other keyboards
        can chime in.<br>
      </div>
    </blockquote>
    <p>Please go back to ::. The double colon was perfectly fine, the
      only thing which was weird was the implicit constant. It's fine
      for constants and inner classes to share the same name scoping
      (i.e. a constant must not share a name with an inner class). But
      an inner class should not be an actual constant.<br>
    </p>
    <p>But otherwise, this was perfectly fine.<br>
    </p>
    <blockquote type="cite" cite="mid:b10ba5b6-8427-4efd-b183-7902b349673f@app.fastmail.com">
      <blockquote type="cite" id="qt" style="">
        <div>I don't&nbsp;think that inner classes are sufficiently valuable<br>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>I'm curious why some people feel this way and why some other
        people are saying the opposite (emphatically). I'll nudge the
        private emails I've received to speak up publicly on the list as
        well. But, why do you feel this way?</div>
    </blockquote>
    <p>I don't know why some people feel this way, but at least with the
      autoloading mechanisms we have in PHP there are definite
      limitations to multiple classes in one file:<br>
      - If you deserialize your data structure and it contains another
      class, whose name does not match the file name, you better hope to
      god that it has been autoloaded already. Surprising failures in
      production follow. (e.g.: the amphp\parallel process runner will
      try to serialize your exception. That's fine. But as soon as it's
      accidentally bubbling up and as it's not autoloadable, the hell
      breaks loose.)<br>
      - Enums or Data Transfer objects specific to one or multiple
      functions of only this specific class would naturally fit into the
      same file. But you can't do it ... because the autoloading might
      try to load the enum first, before the class whose constructor or
      function you want to call is actually loaded.<br>
      - Now, if you actually stuff multiple classes / enums into a
      single file, it's non-trivial to figure out (as the human reader,
      but obviously for the autoloader too) which file to access to read
      up the definition of a specific enum (short of using dedicated
      tooling for it).</p>
    <p>Certainly, one may say - yeah, just religiously use different
      files for ... every ... single ... class.<br>
      But what's the point of that dogma?<br>
      It definitely doesn't help the organization of dedicated helper
      structures tied to a single class.<br>
      It's a tool for organization. It's not complex to understand.</p>
    <p>Outside of very puristic arguments I don't see any reason why one
      would not want inner classes.</p>
    <p>Further, with short classes, should they hopefully be introduced
      as well, it will become trivial to write shapes for any internal
      datastructures - simply using a &quot;class Point(int $x, int $y);
      private Point $pos;&quot; rather than &quot;/** @var list{int, int} */
      private array $pos;&quot;.<br>
      This will be a very ergonomic way to reduce ad-hoc arrays which
      are only typehinted by phpdoc, giving proper typing and also safe
      access to structures via named accessors rather than [0] and [1]
      etc.<br>
    </p>
    <p>Further Questions on the (original) RFC:</p>
    <p>- Why is there a conflict in static properties and the inner
      class name? The former always has a leading $ sigil.</p>
    <p>- Any particular reason to disallow abstract inner classes? Feels
      arbitrary.</p>
    <p><br>
    </p>
    <p>And a note: I consider the inheritance example misguided as
      &quot;static constructors&quot; (static methods which invoke new()) would be
      a better pattern here. Could you maybe come up with another
      example here?<br>
    </p>
    <p><br>
    </p>
    <p>Bob<br>
    </p>
  </body>
</html>

--------------yHQqLdxjYiSMQIPQbhxIX52t--