Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123793
Precedence: bulk
MIME-Version: 1.0
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
In-Reply-To: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
Reply-To: autaut03@gmail.com
Date: Tue, 25 Jun 2024 00:56:00 +0300
Message-ID: <CABigaAWB=X7id9HO+0YcxYy2GH_=N0NfzJyjv+ThuNG=sNUq0w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static class
To: Bilge <bilge@scriptfusion.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000072c168061ba9d925"
From: autaut03@gmail.com (Alex Wells)

--00000000000072c168061ba9d925
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Bilge,

I'm not usually a resident of these discussions, but it seems like this RFC
is heading into a wrong direction. Let me explain: as it currently stands,
static properties and methods live separately from instance properties and
methods. That means a couple of limitations, namely: a static class member
can never implement an interface's contract, and hence a static class could
never be used as an instance; static class members have a separate
reflection API; static class members cannot have expression initializers;
there's no static constructor; and so on. Adding `static classes` would not
solve any of the above issues, and they would still be barely useful.

To counter these issues, Kotlin has a concept of `data objects`: <
https://kotlinlang.org/docs/object-declarations.html#data-objects>. They
look like regular classes, but only one instance of a data object is
created - when it's first accessed by other code. The closest alternative
in PHP would be an enum with a single case. Unlike static classes, `data
objects` don't have any of the problems associated with static members.

They can be passed around as an instance of a class. This allows
implementing interfaces, and replacing a `data object` with a regular class
instance without having to change all member access from static to
instance. They would also be able to inherit the syntax and semantics of
regular class constructors:

```
object Converter {
    private array $map =3D new Map();

    public function __construct() {
        $this->map['miles to km'] =3D 1.6;
    }

     public function convert(string $type, float $value): float {
        return $value * $this->map[$type];
    }
}

doSomeConversion(Converter::object);

// If `Converter` is ever to become a regular class, none of the related
code would require changes.
function doSomeConversion(Converter $converter) {
    $result  =3D $someUtils->convert('miles to km', 123);
}
```

That would be functionally equivalent to:

```
class Converter {
    private static self $instance;

    public static function instance(): self {
        return self::$instance ??=3D new self();
    }

    public function convert(float $something): float {}
}

doSomeConversion(Converter::instance());
```

Of course, this is already possible, as shown in the second example. But so
is this RFC. Implementing data objects would actually bring them on-par
with regular classes, and likely cause less drama overall.

On Mon, Jun 24, 2024 at 2:14=E2=80=AFAM Bilge <bilge@scriptfusion.com> wrot=
e:

> Hi Internals!
>
> I am pleased to present my first RFC: Static class
> <https://wiki.php.net/rfc/static_class>.
>
> This work is based on the previous discussion thread on this list of the
> same name, and hopefully captured all the relevant details,
> notwithstanding anything unanticipated that may present itself during
> the implementation. Let me know if you feel anything important has been
> missed. I am aware it omits to mention specifics about messages so
> emitted when runtime or compile-time errors occur, but I anticipate this
> can be hashed out in the PR, unless consensus indicates otherwise.
>
> I am aware this idea is not supported by everyone, but there seemed to
> be enough positive voices for it to be worth a shot. I'd like to get a
> better idea of where people might stand when it comes down to a vote,
> now there is a formal RFC, so we know whether it's worth completing the
> implementation, although any sentiments so proffered are of course not a
> commitment to vote any particular way and nobody should feel compelled
> to speak to that unless comfortable. Looking forward to feedback!
>
> Cheers,
> Bilge
>

--00000000000072c168061ba9d925
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Bilge,<div><br></div><div>I&#39;m not usually a reside=
nt of these discussions, but it seems like this RFC is heading into a wrong=
 direction. Let me explain: as it currently stands, static properties and m=
ethods live separately from instance properties and methods. That means a c=
ouple of limitations, namely: a static class member can never implement an =
interface&#39;s contract, and hence a static class could never be used as a=
n instance; static class members have a separate reflection API; static cla=
ss members cannot have expression initializers; there&#39;s no static const=
ructor; and so on. Adding `static classes` would not solve any of the above=
 issues, and they would still be barely useful.</div><div><br></div><div>To=
 counter these issues, Kotlin has a concept of `data objects`: &lt;<a href=
=3D"https://kotlinlang.org/docs/object-declarations.html#data-objects">http=
s://kotlinlang.org/docs/object-declarations.html#data-objects</a>&gt;. They=
 look like regular classes, but only one instance of a data object is creat=
ed - when it&#39;s first accessed by other code. The closest alternative in=
 PHP would be an enum with a single case. Unlike static classes, `data obje=
cts` don&#39;t have any of the problems associated with static members.=C2=
=A0</div><div><br></div><div>They can be=C2=A0passed around as an instance =
of a class. This allows implementing interfaces, and replacing a `data obje=
ct` with a regular class instance without having to change all member acces=
s from static to instance. They would also be able to inherit the syntax an=
d semantics of regular class constructors:</div><div><br></div><div>```</di=
v><div>object Converter {</div><div>=C2=A0 =C2=A0 private array $map =3D ne=
w Map();</div><div><br></div><div>=C2=A0 =C2=A0 public function __construct=
() {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;map[&#39;miles to km&#39;] =
=3D 1.6;<br>=C2=A0 =C2=A0 }</div><div><br>=C2=A0 =C2=A0=C2=A0=C2=A0public f=
unction convert(string $type, float $value): float {<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 return $value * $this-&gt;map[$type];<br>=C2=A0 =C2=A0 }<br>}</d=
iv><div><br></div><div>doSomeConversion(Converter::object);<br></div><div><=
br></div><div>// If `Converter` is ever to become a regular class, none of =
the related code would require changes.</div><div>function doSomeConversion=
(Converter=C2=A0$converter) {</div><div>=C2=A0 =C2=A0 $result=C2=A0 =3D $so=
meUtils-&gt;convert(&#39;miles to km&#39;, 123);<br>}</div><div>```</div><d=
iv><br></div><div>That would be functionally equivalent to:</div><div><br><=
/div><div>```</div><div>class Converter {</div><div>=C2=A0 =C2=A0 private s=
tatic self $instance;</div><div><br></div><div>=C2=A0 =C2=A0 public static =
function instance(): self {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return se=
lf::$instance ??=3D new self();</div><div>=C2=A0 =C2=A0 }<br><br>=C2=A0 =C2=
=A0 public function convert(float $something): float {}</div><div>}</div><d=
iv><br></div><div>doSomeConversion(Converter::instance());<br></div><div>``=
`</div><div><br></div><div>Of course, this is already possible, as shown in=
 the second example. But so is this RFC. Implementing data objects would ac=
tually bring them on-par with regular classes, and likely cause less drama =
overall.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, Jun 24, 2024 at 2:14=E2=80=AFAM Bilge &lt;<a href=
=3D"mailto:bilge@scriptfusion.com">bilge@scriptfusion.com</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Internals!<br>
<br>
I am pleased to present my first RFC: Static class <br>
&lt;<a href=3D"https://wiki.php.net/rfc/static_class" rel=3D"noreferrer" ta=
rget=3D"_blank">https://wiki.php.net/rfc/static_class</a>&gt;.<br>
<br>
This work is based on the previous discussion thread on this list of the <b=
r>
same name, and hopefully captured all the relevant details, <br>
notwithstanding anything unanticipated that may present itself during <br>
the implementation. Let me know if you feel anything important has been <br=
>
missed. I am aware it omits to mention specifics about messages so <br>
emitted when runtime or compile-time errors occur, but I anticipate this <b=
r>
can be hashed out in the PR, unless consensus indicates otherwise.<br>
<br>
I am aware this idea is not supported by everyone, but there seemed to <br>
be enough positive voices for it to be worth a shot. I&#39;d like to get a =
<br>
better idea of where people might stand when it comes down to a vote, <br>
now there is a formal RFC, so we know whether it&#39;s worth completing the=
 <br>
implementation, although any sentiments so proffered are of course not a <b=
r>
commitment to vote any particular way and nobody should feel compelled <br>
to speak to that unless comfortable. Looking forward to feedback!<br>
<br>
Cheers,<br>
Bilge<br>
</blockquote></div>

--00000000000072c168061ba9d925--