Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126609 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 31D151A00BC for ; Thu, 6 Mar 2025 22:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741298624; bh=uuok+1EcD7cd5OAs+Ba2vnCgji4l3dNM/8CgAaCCgkU=; h=Date:From:To:In-Reply-To:References:Subject:From; b=IRRMhaGx7ABUbS6sRzk1qQyG2Omf3BdSEi87WGQ89PG8mZuN4M6eMdYRj2uLB18R0 ATbggUzNT8OidrNiiU3EnibEkAExyBTeeILPxcsFMq10wAI5Gj9sLUXKd2iyFDCxkX Gd/HzbhhQ4KQjPjpNhAbh04eq0xc1qqJ6QsGaAxzDvc0c91f5K3DVPn2SczTLPjiLv RS53tlVo+C+oMFGo5dK//DbPD/DtLQNrfZiyfNPWdtn1IdtEMVzReiPQbnBXi5zRCc jjZpQCejxScIH7IJXHLa5UsqhUKUUeMK0Y6hUBZachtGoEMDWhYNp7/xbQMmKOJTrw Kkh+K3oLgK7rg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A4EB718007C for ; Thu, 6 Mar 2025 22:03:43 +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=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 6 Mar 2025 22:03:43 +0000 (UTC) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 8EA8A1140144; Thu, 6 Mar 2025 17:06:18 -0500 (EST) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-11.internal (MEProxy); Thu, 06 Mar 2025 17:06:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1741298778; x=1741385178; bh=xMynVo/RW7 KqlEbxX4G7qMyaPHz15utykcXt+P+mLRE=; b=K8W6/8dHuzsTzYD/1V8HLxnf4g UyWuvTxp68AWnPpZ4qaFuSGhGe586Y8JHn6s3PqkJ02e6ZZxu91LOrJJErcBVm1k Eo8z390NeIheBOWLp6yGAZIPdkMK/LgR8+YHnMGd7h4dGqQ70OcIw61Hc6uZdhiS +ZVe+OGACk+sC+bzPUMbASG21zWwIwB7kpX8CRY1O41e7D7CQGplA8SaCn4Zwzck jC9oTa2ZSBnIn+HaZQQS3G/sAJg+AidWXzvb0j5lfXcJ0QV//CQUpmQhfxcLgAro 2Yv3guXUR9fSHzDib+TyDPnPtJZbS2evSd9l2m8Jt2adBryoEWdRxCoUxV+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1741298778; x=1741385178; bh=xMynVo/RW7KqlEbxX4G7qMyaPHz15utykcX t+P+mLRE=; b=T3tFWbi7V2GII1tIPEjcb/UNw6SX3bn7jCqtGajJTp7ZteaRgXq MxMUKgUTzGgd84IY2r3witehQd1Cn4pn3wTc/lNa6fIIpCoJXLJH8uzjNz0t7Xxp HLGp4fvbTnprQI/sHpU/xy9PtvBamfp7tgaGSw63JQHJ057piskdXgw6bJJDrTn6 cBTx1Vsc+lft8ELfrCq1k289AOnX3ev7kYMbVf/ZLQ3UTIZx4S7muCZG7E9R+JGu 3Rw+YjTUsYOB/ySreUKuMEUdWzq5ew4qAH6kjU94Dgl/H7nx6O1D9e36TA9aSQ05 gqFoImx9mNYyXk81svOaareiMEuVkvll4Yg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddutdekledtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvffkjghfufgtsegrtderreertdej necuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtg houggvsheqnecuggftrfgrthhtvghrnheptdeujedttefhueelhfdtleeiudetlefftddu leehffegtdeihefhleeijefgveegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghp thhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepthhimhessggrshhtvg hlshhtuhdrsggvpdhrtghpthhtohepughoshhstghhvgdrnhhivghlshesghhmrghilhdr tghomhdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id E6884780068; Thu, 6 Mar 2025 17:06:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Thu, 06 Mar 2025 23:05:57 +0100 To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= , "Niels Dossche" , internals@lists.php.net Message-ID: In-Reply-To: <8303823b-a193-411f-bb60-c0221e7f29dc@bastelstu.be> References: <8303823b-a193-411f-bb60-c0221e7f29dc@bastelstu.be> Subject: Re: [PHP-DEV] RFC: short and inner classes Content-Type: multipart/alternative; boundary=bd88336afa6845aab0f38c3df0d87622 From: rob@bottled.codes ("Rob Landers") --bd88336afa6845aab0f38c3df0d87622 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 6, 2025, at 22:00, Tim D=C3=BCsterhus wrote: > Hi >=20 > On 3/6/25 20:08, Niels Dossche wrote: > > What I'm less in favor of is the implementation choice to expose the= inner class as a property/const and using a fetch mode to grab it. > > That feels quite weird to me honestly. How did you arrive at this ch= oice? >=20 > Somewhat relatedly, the RFC does not mention how the choice of `::` as=20 > the separator interacts with the following features (i.e. what will th= e=20 > result of each of the statements be): Sorry to double post, but before updating the RFC, I figure I'll go ahea= d and answer here and see if it is what you expect. >=20 > Closure::fromCallable('Outer::Inner::method'); You end up with: object(Closure)#1 (1) { ["function"]=3D> string(20) "Outer::Inner::method" } > new ReflectionMethod('Outer::Inner::method'); The current implementation returns an error here, but it should give you= an actual ReflectionMethod. I'll have to take a look and see what is go= ing on. > defined('Outer::Inner'); This returns: `true`. > constant('Outer::Inner'); This returns: string(12) "Outer::Inner" > $inner =3D 'Inner'; > Outer::{$inner}; This does nothing (but resolves to "Outer::Inner") > =E2=80=A6 and any other meta-programming functionality working on clas= s=20 > constants or static methods. >=20 > Also, what will happen for: >=20 > class P { > class Inner { } > } >=20 > class C extends P { > const Inner =3D 'x'; > } >=20 > (and vice versa) This is a really good one. If for no other reason than I did a really po= or job of explaining resolution(?) in the RFC. `P::Inner` belongs to `P`= , not to `C`, so you can do `new C::Inner()` and it will resolve to `P::= Inner()`: object(P::Inner)#2 (0) { } As with other static things in PHP, you can do some really strange thing= s like this. This is similar to how you can redefine static constants in= subclasses. My main goal is to prevent exactly this type of confusion: new C::Inner()=20 vs.=20 echo C::Inner. > Somewhat relatedly, the RFC does not mention how the choice of `::` as=20 > the separator This felt the most natural to me, but as with all syntax on this list, I= 'd be interested in other colors to paint the bikeshed! Especially ones = that I may not have previously considered! =E2=80=94 Rob --bd88336afa6845aab0f38c3df0d87622 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, = 2025, at 22:00, Tim D=C3=BCsterhus wrote:
Hi

On 3/6/25= 20:08, Niels Dossche wrote:
> What I'm less in favor o= f is the implementation choice to expose the inner class as a property/c= onst and using a fetch mode to grab it.
> That feels qu= ite weird to me honestly. How did you arrive at this choice?

Somewhat relatedly, the RFC does not mention how the c= hoice of `::` as 
the separator interacts with the fo= llowing features (i.e. what will the 
result of each = of the statements be):

Sorry t= o double post, but before updating the RFC, I figure I'll go ahead and a= nswer here and see if it is what you expect.


 &n= bsp;   Closure::fromCallable('Outer::Inner::method');

You end up with:

object(Closure)#1 (1) {
  ["function"]=3D>=
  string(20) "= Outer::Inner::method"
}

     new ReflectionMethod('Outer::Inner::met= hod');

The current implementat= ion returns an error here, but it should give you an actual ReflectionMe= thod. I'll have to take a look and see what is going on.
<= br>
  = ;   defined('Outer::Inner');

This returns: `true`.

     constant('Oute= r::Inner');

This returns:
<= /div>

string(12) "Outer::Inner"

     $inner =3D 'Inner';
     Outer::{$inner};
This does nothing (but resolves to "Outer::Inner")

=E2=80= =A6 and any other meta-programming functionality working on class <= br>
constants or static methods.

= Also, what will happen for:

  &nb= sp;  class P {
      &n= bsp;  class Inner { }
     }
<= /div>

     class C extends P {
          const= Inner =3D 'x';
     }
<= br>
(and vice versa)

This is a really good one. If for no other reason than I did a really p= oor job of explaining resolution(?) in the RFC. `P::Inner` belongs to `P= `, not to `C`, so you can do `new C::Inner()` and it will resolve to `P:= :Inner()`:

object(P::Inner)#2 (0) {
}

As with ot= her static things in PHP, you can do some really strange things like thi= s. This is similar to how you can redefine static constants in subclasse= s.

My main goal is to prevent exactly this = type of confusion:

new C::Inner()
vs.
echo C::Inner.

Somewhat relatedly, the RFC = does not mention how the choice of `::` as 
the separ= ator

This felt the most natura= l to me, but as with all syntax on this list, I'd be interested in other= colors to paint the bikeshed! Especially ones that I may not have previ= ously considered!

=E2=80=94= Rob
--bd88336afa6845aab0f38c3df0d87622--