Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126606
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 06 Mar 2025 13:33:56 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <f55878fc-5054-4436-850f-14d9c2304f60@app.fastmail.com>
In-Reply-To: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Mar 5, 2025, at 5:11 PM, Rob Landers wrote:
> Hello PHP Internals,
>
> I'd like to introduce my RFC for discussion:=20
> https://wiki.php.net/rfc/short-and-inner-classes

I agree with others who have said this should be two RFCs.  They stand a=
lone, but can complement each other well.  That's fine, talk about how t=
hat works, but they're separate RFCs.  (Like we split hooks and aviz.)

I'm broadly in favor of short classes and warm on inner classes, with as=
sorted caveats as below.

## Short classes

The no-method-definitions restriction seems odd to me.  I don't really s=
ee what value that provides.  The main advantages are

1. Even shorter way to define promoted properties for the common case.
2. No need to define a body if you don't need one.

Neither of those conflicts with defining methods.

If the concern is the verbosity of method definitions, well, I tried:

https://wiki.php.net/rfc/short-functions

I still think that would be beneficial, but am frying other fish at the =
moment.

So really, all it need to do is allow inline definition of the propertie=
s by the class name as an alternative to a constructor.

class Point(int $x, int $y) {}

class Rect(Point $tl, Point $br) {
  public method area() {
     /* ... */=20
  }
}

(Also allowing to skip the empty {} is fine with me, but that the last o=
f my concerns.)

The other question is trait usage.  The RFC proposes just shifting that =
up to the declaration line.  That also seems fine to do either way, rega=
rdless of whether there are methods.

My biggest concern with this is that it makes methods and short-classes =
mutually incompatible.  So if you have a class that uses short-syntax, a=
nd as it evolves you realize it needs one method, sucks to be you, now y=
ou have to rewrite basically the whole class to a long-form constructor.=
  That sucks even more than rewriting a short-lambda arrow function to a=
 long-form closure, except without the justification of capture semantic=
s.

Additionally: The RFC doesn't specify if or how properties with hooks ar=
e supported.  That should be defined so we can argue about it. :-)

Additionally: What happens here:

class Point(int $x, int $y);

class 3DPoint(int $z) extends Point;

I have to redeclare all of the parameters from the parent, just to add o=
ne?  That's ugly.=20

## Inner classes

I'm on board with the use case.  What I'm not sure on is inner classes v=
s file-private visibility, something that Ilija was working on at one po=
int and Micha=C5=82 Brzuchalski suggested in his post.  Both solve large=
ly the same problem with different spelling.

Arguably, inner classes have fewer issues with current autoload conventi=
ons.  I must ponder this further.

> However, no classes may not inherit from inner classes, but inner clas=
ses may inherit from other classes, including the outer class.=20

I think you have one too many negatives in that sentence.

--Larry Garfield