Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124975
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 16 Aug 2024 09:17:10 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <79817594-f9a9-4f02-b48a-4bf39e4372e6@app.fastmail.com>
In-Reply-To: 
 <CAAwdEzBWN40q10Q5ua_ZME29dJSqs=BHB1LxJ62mN-vXWNw0xQ@mail.gmail.com>
References: <34548342633f1d87b2fc77c643bd895a18f71b66.camel@ageofdream.com>
 <CAAwdEzBWN40q10Q5ua_ZME29dJSqs=BHB1LxJ62mN-vXWNw0xQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 16, 2024, at 6:35 AM, Alexandru P=C4=83tr=C4=83nescu wrote:
> Hi Nick,
>>=20
>> Is there any interest in having enums as class constants?
>>=20
>> I'm often finding cases where I would like to have an enum inside of a
>> class, but don't want a free-floating enum that's basically like
>> another class.
>>=20
>=20
> ...<snip>...=20
>=20
>>=20
>> class SSHClient {
>>=20
>>    public const enum CommandResult
>>    {
>>        case Success;
>>        case Failure;
>>        case Unknown;
>>        case Timeout;
>>    }
>>=20
>>    // ...
>> }
>>=20
>>=20
>> // Usage:
>>=20
>> SSHClient::CommandResult::Success
>
>
> I feel this topic could be maybe more broad and be called "nested=20
> classes" that are already supported in multiple languages: Java, Swift=
,=20
> Python, C#, C++, JavaScript, etc.
>
> The syntax you showed is usually identical with what other languages=20
> use, except that probably the const is unnecessary.
> The nested class can have visibility as sometimes having it private=20
> makes sense.
> Accessing it through `::` is probably fine, but a deeper look at the=20
> grammar might be necessary.
> The nested class would have access to parent class private properties=20
> and methods.
>
> I also mentioned this topic on the subject of defining a type in an=20
> autoloader compatible way.
> And indeed, a type could also be defined nested in a class if we want=20
> to support that as well.
>
> Now, this feature is not simple, and I think it needs proper=20
> sponsorship from someone experienced with internals.
>
> Regards,
> Alex

I agree with Alexandru.  Since enums are 90% syntactic sugar over classe=
s, "inner enums" would be 80% of the way to "inner classes".  And I woul=
d be in favor of inner classes. :-)  There's a lot of potential benefits=
 there, but also a lot of edge cases to sort out regarding visibility, w=
hat is allowed to extend from what, etc.  But that would support inner e=
nums as well.

Based on our sibling languages (Java, Kotlin, C#, etc.), the syntax woul=
d likely be something like:

class Outer
{
  private string $foo;

  public function __construct(protected Sort $order) {}

  enum Sort
  {
    case Asc;
    case Desc;
  }

  class Inner
  {
    public function __construct(private string $baz) {}
  }

  private class HIdden
  {
    public function __construct(private string $baz) {}
  }
}

Which enables:

$case =3D Outer::Sort::Asc;
$o =3D new Outer($case);

$i =3D new Outer::Inner('beep');

$h =3D new Outer::Hidden('beep'); // Visibility error

I would have to research to see if other languages did this, but one opt=
ion would be to allow an inner class to extend an outer class even if it=
's final, which would essentially give us sealed classes for free:

final class Outer
{
  class InnerA extends Outer {}

  class InnerB extends Outer {}

  class InnerC extends Outer {}
}

// But this is still not OK:
class Sibling extends Outer {}

Note: I have no idea how difficult/complicated this would be, but I woul=
d be in favor of exploring it.

--Larry Garfield