Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123794
Message-ID: <942bd631-a7c7-4705-af90-b00a9acf7231@scriptfusion.com>
Date: Mon, 24 Jun 2024 23:56:34 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Static class
To: autaut03@gmail.com
Cc: php internals <internals@lists.php.net>
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <CABigaAWB=X7id9HO+0YcxYy2GH_=N0NfzJyjv+ThuNG=sNUq0w@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CABigaAWB=X7id9HO+0YcxYy2GH_=N0NfzJyjv+ThuNG=sNUq0w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: bilge@scriptfusion.com (Bilge)

On 24/06/2024 22:56, Alex Wells wrote:
> 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>.

Hi Alex,

If you wish to implement data objects, what part of the current proposal 
precludes you from doing so?

Cheers,
Bilge