Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126759
Content-Type: multipart/alternative;
 boundary="------------uoD5UGSrtAFn91vR9zhluIgc"
Message-ID:
 <AM8P250MB0170D2DDCF2E8EF8345E888DE2D22@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Fri, 14 Mar 2025 18:45:29 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC: short and inner classes
To: Ilija Tovilo <tovilo.ilija@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAPyj-LAz=3yX7mCYOijw2irrubgs2b3Piqy42_jpkek5ctKkWA@mail.gmail.com>
 <AM8P250MB0170E8274E56E96B4962578BE2D32@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <CAPyj-LBB6VsF6u2X_=SHpgv-UYPAjX4tKgDgZrEE+QtTwfz+_w@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAPyj-LBB6VsF6u2X_=SHpgv-UYPAjX4tKgDgZrEE+QtTwfz+_w@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|DU2P250MB0383:EE_
X-MS-Office365-Filtering-Correlation-Id: 947f00b1-40ae-4f0a-643b-08dd6320035e
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|15080799006|461199028|8022599003|12050799009|19110799003|7092599003|5072599009|8060799006|12121999004|3412199025|19061999003|440099028|41001999003;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NkQ0b3FjWGY1V3ZrV0pmWEZRSTJ1OHVORWxHZGVQUFNuL2RMVytPTit0RmY2?=
 =?utf-8?B?Y2VWTVcxa0U0S2dJRy90ODcraVpCVmFMR3dFczNwUDhZc1JjTDNDR1B1aXF4?=
 =?utf-8?B?S3NTUGpjTGdZWDU0bG5INjFjdER5R1pZWjdvWStobjRrdTIrRVlCOE1RcW8w?=
 =?utf-8?B?Z3NnZ1ZZaUJCT3Y1MExXUFlXUFpIZ2FncldFQ3M0dkRRQ0k1SzZoK1ZDY0tn?=
 =?utf-8?B?eFlKb2tZczczY0M2RjRIMDByMytnT0QrYWNxTit6am1WWUptZWNJVUlCM0tj?=
 =?utf-8?B?NUo4dHRlOTVEeE9Nbjd0R1lzNXpSMFI0QmUwa0dWUXJmR3lBbDBRMlpSUm5W?=
 =?utf-8?B?YjJxWDVJZ1J6SFYwc3pPV3Y1RVRXRmU5WGkwcTJDaHUzblh2bUJxYlZoZVBq?=
 =?utf-8?B?cVFENi90V3p4ckVtMUJ4ejhtdUdzR21NN3ZvbUFxbjhGRmU2NG9xNEVsTzRX?=
 =?utf-8?B?R0VkaUVBaUwvUEJFMktNa2JqMEp4VzZEUk9IWktaN3F4cGs2V0hHdU9QbThs?=
 =?utf-8?B?YmIvcG4yRzlsNXllZmYvblpHZjhYWHhYbW9KamlFZlNvbnhLdXRVaGlvRUNz?=
 =?utf-8?B?UjF1TWNZVCsrUFlNUUxsSFM4UVpVb3JLU2RKVFJ0UHcwZC9VdXFtM3FLcHdD?=
 =?utf-8?B?VEZiYnBQZVlIdXA2dTRha1JLOXJjb1gvdlN0aDNqTlprOVJuSmplcktoRThK?=
 =?utf-8?B?NXFSdWdlM25UeHVmaGVZNlZqdjV4Vk1GdGYraHo2TDM5amxPSVpYMWtFb2Ir?=
 =?utf-8?B?aUtGUWJhQzJmV2pVc2RzU2NIOTlidWliNkVyNU56Q0RXN0RzT0owZWhuRVVj?=
 =?utf-8?B?aVV4dWYvWnRMR1hMWldTWHllRFU4VlRoOVpEaDNmaHVqZ2lpcWRBNTlFdmlR?=
 =?utf-8?B?Nm5UUDNic1d6TzZJOEVmQm5VS1d2VG4wa0daUTJRa1JxMGRpSG9pM0F2S01q?=
 =?utf-8?B?TWRNN3ZwZDd3YSs3a042NTRRTTRLcHlKTHJJaEpieGlyeERJV3M4WW4zbXVN?=
 =?utf-8?B?OW1sU2dtYWRkamcycElqWGNEalFGUGo2aURBVFlWNUxGVHJRRm1OZFVYbld3?=
 =?utf-8?B?TXVnc3B3M0xJYWM2Z01tWlJ2dlpUUjdMOWpiTmMyU3lzOFhFT0N1RWJ6NHJC?=
 =?utf-8?B?aXUwdVZiZFNxb0t5bmprcmJkTFIzaVF0SGxSTEpZUEVtU3kwMzBWcS94aVFT?=
 =?utf-8?B?SnlrTndOU1NRWVRUaXNnVExCeGd0SFFFckdVbTBORkZleTdKR0FIN1M1bmMv?=
 =?utf-8?B?cVMzblhpWlFYYXNhTmZVd0hleWZMTjRZdFNOSE1Manl4eDFuS3A5KzQvczhv?=
 =?utf-8?B?NWhxTEJ5OUtLeGl6ai9tRUJqVGUyN3YxeG5xUHFZbGthUEUvcWdOWTVIMEt6?=
 =?utf-8?B?a1N2cWJDYWVVaHlnZjFEdTdyS1NmV1FJakJpd29mc3lnTVpTMWtvMHM3VWRu?=
 =?utf-8?B?ZVp6cDJiR1R6cm93eE1ld1lNMklmYnhFSWZPdTB3OGhFSTNmeDF5bnhFUStB?=
 =?utf-8?B?dmREU1MrNUc4SThKUmtJSDBqejFld3R3YnNWd1czaGVxakhmZ1kvMGtWWmYv?=
 =?utf-8?B?VW1RRWQ4UGsxRkRzNVJsZFR2Zk5NcmxsU3JGdHlaU3QvQW5WN2pkZFIrRjUz?=
 =?utf-8?Q?hZO8igSDU97UkxMajbXhJmQvQv+RqPUJ9ciInFvbMC0M=3D?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?M0drRFNFNGllUTg3MDFTdDdDMVFLQjVEaWZzT1FObGZnVHFUMDNaVE9Uenpw?=
 =?utf-8?B?T2Yyd2lvOExpemRaZFE5RzA4UFE2dW1ZY09Ma2xDUU5MbXhvWlA2L0o0anl4?=
 =?utf-8?B?ejZjbmE3bE14M2JSVVNRT2V3TTNMUyt1cU5TT3lmY2RoN3IwV2VtM2VhdmJP?=
 =?utf-8?B?clBOeW1tY0VHVTRYVGxYeXkzbmxHQi9ZTzdCSWp1amlJQmRNQmVtU0diR3dj?=
 =?utf-8?B?YXE4a3pZeHNSb0xLTXk5ZVFFaHpiWjQ1SlZpQzdLNUFSdy9nRG96Z01UZmll?=
 =?utf-8?B?alhQYXM1TUhFcUN0M0Zwb1ZpbDZQL3RHT1c3MEN2QTZFcjVWM0lEK210QjFY?=
 =?utf-8?B?dk50bkd5bVBacWVCY2JYdlZETEljZi81bU1HamxweXB6dEE5ZE85dk0ybnpI?=
 =?utf-8?B?TUd2a3JlN3orWDJuY252blBJOGZER2xmZHoraDd6Mm1uM0lkekZRN1B3c3pP?=
 =?utf-8?B?NThUbjR5MlJPK1F6djMvb0QraEx4ZlBaTlJieVY3em5DZFdWeDJnejQvSnp6?=
 =?utf-8?B?RWZaZ1RYaVFSSXZEUWNPc0poNmdZVG4xendJQnFSVS9aQTVLYS9xZnJZQ3VS?=
 =?utf-8?B?UXdpR05Mc3lCRXpKbHRZT1VhdHExcXc4Q0hMSkdYZnFVSDRtU2hMRFc2SUZR?=
 =?utf-8?B?RHJ5K2RjVnptRUlKMjBPL2JvNzFHWVk4TnVhNm5VOXNzdWd3S3VmbG9wSWdD?=
 =?utf-8?B?bndJd1VuZnVRenhsSVIwM3lMUmU4UE1ZR21laEh0VTNYSTJVSGN4RTdRdTNY?=
 =?utf-8?B?V1pxUFQvelB6cHJDRFFBWUpTSDFib0RrRUpVK2p5N29RUmM5emlNQnZmcEg1?=
 =?utf-8?B?ZTVDNGhYQUc5R3ZUVWYyaU5scWMyU0dsWDFiZG1GczIyZ3VSRU1IaTN0MG9w?=
 =?utf-8?B?bk9KcFZYYUc0cTdOZFR1dStSZ0xXQXg0ejhjRTQ1cmd2aExOcmlGNkFSYzNu?=
 =?utf-8?B?b0M5K1I3ZC9aVFN5L0g5dVBwU0MxTVFNOVhUVnJFRXN2TXU0ZGhtN1lKZHpl?=
 =?utf-8?B?OVNRQ1dEMG5uQTJpOUlhTGNrWHRtV0RlZVl2UndoVVFMZGtJUmFkVm5xbzgz?=
 =?utf-8?B?bzFiMkhVOHh2R2tubkZPVXVsbkF5WmJ0U2ZsR0RGcnBXUTVKS0R6a2RPbHNu?=
 =?utf-8?B?Smp1eVN2VTVFVDVlRDc1YXAwK1BMZlQrN2grdU94LzloSC9pUHB0QmpzS2pa?=
 =?utf-8?B?dnpwTEFXYW54U0ZsRmtkdDlneHBDSWhrTkNjU2U5WHlzRGN5TDBYOFgrT0FI?=
 =?utf-8?B?a0JoYXZkTnF3eUYzWGtTUkZxSWo1YTBoQ1pqZ1R1amh0MTRkUlVaUXk2MFJw?=
 =?utf-8?B?TW54Uk1sdytNM1NiSUlFc2R4Z1hHcDBtdWVRT3kxN01NZEN4SGJDQmxvQ252?=
 =?utf-8?B?dFQxUm80OSszM2RVUFQrVExTaWFQVU9tbzlBYTdyRXVPUU5jaU0zZmVsMVds?=
 =?utf-8?B?RTZUVlIzZk56MjdTdU9ueUN5cGczVi9pRHhPYlBjaUxFUno1Vy9DemtXQWtX?=
 =?utf-8?B?WlZWUzJRelNtbWtZa0lUOTlsVHNCUkQvajRFeHJJY0J4KzdrbXFhaEV0ZDBL?=
 =?utf-8?B?cU5KWTlVV1NzcHBEclFyS0NNVmdqZDJzQXdvc2RaZldhZ3pGdXovSktCc0Y1?=
 =?utf-8?B?aThLTkhMVS9UY1hyekg2NkNqRHZJV3lJUUEwaC9SYWw4UWFVcTBwbEw4UXMx?=
 =?utf-8?B?TGZ2dXV0NFJYRVI0dU96Y3VYYlFkajEyOXlleFUyeEt5SzNnSDJkQ2pIRW9y?=
 =?utf-8?Q?Ei/IvfUOqhD4J0WGDU=3D?=
X-OriginatorOrg: sct-15-20-7784-11-msonline-outlook-95b76.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 947f00b1-40ae-4f0a-643b-08dd6320035e
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2025 17:45:30.7250
 (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: DU2P250MB0383
From: bobwei9@hotmail.com (Bob Weinand)

--------------uoD5UGSrtAFn91vR9zhluIgc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Ilija,

On 14.3.2025 17:09:40, Ilija Tovilo wrote:
> Hi Bob
>
> On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand<bobwei9@hotmail.com> wrote:
>> On 6.3.2025 23:20:37, Ilija Tovilo wrote:
>>
>>> I would also like to echo what has been said about the :: operator,
>>> which feels out of place. I understand that \ comes with additional
>>> autoloading challenges, namely requiring a fallback autoloading
>>> strategy that currently does not conform to PSR-4.
>> Could you please elaborate on why the :: operator feels out of place?
>>
>> \ is a namespace separator.
>>
>> :: is a class scoping separator.
>>
>>
>> You, yourself did decide to use nested :: for property hook scoping, like parent::$x::set() - a property scoped within a class, having methods.
>> The same applies here - it's a class scoped within a class, having methods.
>>
>> Breaking from these patterns seems very surprising to me.
> :: is an operation performed on the class. E.g. fetch a static
> property, fetch a constant, call a static method, while \ is part of
> the class name. The way I see it, the outer class can simply add an
> additional namespace component to the inner class.

I'd consider this a very internals perspective. Yes, internally it will 
include its separator and the reported name includes the separator.

 From a user perspective, the class is fetched (an operation!) from its 
defining class.

Similarly, static::Foo (if it is going to be re-introduced) and 
parent::Foo, are definitely *fetches* of the class.

And as such, it should also have the :: operator.

> class Foo {
>      class Bar {} // Called Foo\Bar
>
>      public Bar $bar;
> }
>
> This is dead simple, it doesn't change any assumptions about class
> names by embedding new symbols, it doesn't need a new operator, you
> can refer to the class with its short name from inside the outer class
> without `self:>`, which is shorter and more straight forward, `use
> Foo\Bar;` will just work in other classes, etc.

use Foo\Bar; to reference to an inner-class sounds very much like a bad 
idea to me.

Inner classes are supposed to be intrinsically tied to their containing 
class, and making it work like a namespace reduces the association a lot.

I desire explicitness, which a different symbol can give you. Using 
namespace-syntax makes the autoloading and human resolution more complex 
for no gain.

Removing the self:: seems enticing, but it breaks at the moment you add 
inheritance. Then you'll have to either make it a binding-time decision 
whether it's a namespace access or a parent inner class access.

class Foo { class Bar {} } class Baz extends Foo { public Bar $bar; // 
??? parent::Bar would be obvious. }

Certainly you could opt for only removing self:: in classes they are 
declared in, but what's then the syntax when referring to an inner class 
up the inheritance chain? parent\Foo? That's plain weird. Or explicitly 
requiring the concrete class name the inner class is implemented on? 
Then this becomes the only weird case which cannot be accessed through 
the scope resolution. Why would one want that?

> One thing this approach breaks is that it doesn't allow for
> polymorphic inner class resolution, i.e. static:>Bar. But given this
> was removed anyway, that point no longer applies. This can also easily
> be replicated by a simple method:
>
> class Foo {
>      class Bar {}
>
>      public function createBar(): Bar {
>          return new Bar();
>      }
> }
>
> Except this is actually type-safe, because the return value of
> createBar() must stay compatible with Foo\Bar.

I don't care much about static resolution for this, but self:: and 
parent:: are relevant.

Bob

--------------uoD5UGSrtAFn91vR9zhluIgc
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 Ilija,<br>
    </p>
    <div class="moz-cite-prefix">On 14.3.2025 17:09:40, Ilija Tovilo
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAPyj-LBB6VsF6u2X_=SHpgv-UYPAjX4tKgDgZrEE+QtTwfz+_w@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">Hi Bob

On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand <a class="moz-txt-link-rfc2396E" href="mailto:bobwei9@hotmail.com">&lt;bobwei9@hotmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">
On 6.3.2025 23:20:37, Ilija Tovilo wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="" class="moz-quote-pre">I would also like to echo what has been said about the :: operator,
which feels out of place. I understand that \ comes with additional
autoloading challenges, namely requiring a fallback autoloading
strategy that currently does not conform to PSR-4.
</pre>
        </blockquote>
        <pre wrap="" class="moz-quote-pre">
Could you please elaborate on why the :: operator feels out of place?

\ is a namespace separator.

:: is a class scoping separator.


You, yourself did decide to use nested :: for property hook scoping, like parent::$x::set() - a property scoped within a class, having methods.
The same applies here - it's a class scoped within a class, having methods.

Breaking from these patterns seems very surprising to me.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
:: is an operation performed on the class. E.g. fetch a static
property, fetch a constant, call a static method, while \ is part of
the class name. The way I see it, the outer class can simply add an
additional namespace component to the inner class.</pre>
    </blockquote>
    <p>I'd consider this a very internals perspective. Yes, internally
      it will include its separator and the reported name includes the
      separator.</p>
    <p>From a user perspective, the class is fetched (an operation!)
      from its defining class.</p>
    <p>Similarly, static::Foo (if it is going to be re-introduced) and
      parent::Foo, are definitely *fetches* of the class.</p>
    <p><span style="white-space: pre-wrap">And as such, it should also have the :: operator.
</span></p>
    <blockquote type="cite" cite="mid:CAPyj-LBB6VsF6u2X_=SHpgv-UYPAjX4tKgDgZrEE+QtTwfz+_w@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">class Foo {
    class Bar {} // Called Foo\Bar

    public Bar $bar;
}

This is dead simple, it doesn't change any assumptions about class
names by embedding new symbols, it doesn't need a new operator, you
can refer to the class with its short name from inside the outer class
without `self:&gt;`, which is shorter and more straight forward, `use
Foo\Bar;` will just work in other classes, etc.</pre>
    </blockquote>
    <p><span style="white-space: pre-wrap">use Foo\Bar; to reference to an inner-class sounds very much like a bad idea to me.</span></p>
    <p><span style="white-space: pre-wrap">Inner classes are supposed to be intrinsically tied to their containing class, and making it work like a namespace reduces the association a lot.</span></p>
    <p><span style="white-space: pre-wrap">I desire explicitness, which a different symbol can give you. Using namespace-syntax makes the autoloading and human resolution more complex for no gain.</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p><span style="white-space: pre-wrap">Removing the self:: seems enticing, but it breaks at the moment you add inheritance. Then you'll have to either make it a binding-time decision whether it's a namespace access or a parent inner class access.</span></p>
    <p><span style="white-space: pre-wrap">class Foo {
	class Bar {}
}
class Baz extends Foo {
	public Bar $bar; // ??? parent::Bar would be obvious.
}</span></p>
    <p><span style="white-space: pre-wrap">Certainly you could opt for only removing self:: in classes they are declared in, but what's then the syntax when referring to an inner class up the inheritance chain? parent\Foo? That's plain weird.
Or explicitly requiring the concrete class name the inner class is implemented on? Then this becomes the only weird case which cannot be accessed through the scope resolution. Why would one want that?
</span></p>
    <blockquote type="cite" cite="mid:CAPyj-LBB6VsF6u2X_=SHpgv-UYPAjX4tKgDgZrEE+QtTwfz+_w@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">One thing this approach breaks is that it doesn't allow for
polymorphic inner class resolution, i.e. static:&gt;Bar. But given this
was removed anyway, that point no longer applies. This can also easily
be replicated by a simple method:

class Foo {
    class Bar {}

    public function createBar(): Bar {
        return new Bar();
    }
}

Except this is actually type-safe, because the return value of
createBar() must stay compatible with Foo\Bar.</pre>
    </blockquote>
    <p>I don't care much about static resolution for this, but self::
      and parent:: are relevant.</p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p><span style="white-space: pre-wrap">Bob
</span></p>
  </body>
</html>

--------------uoD5UGSrtAFn91vR9zhluIgc--