Everything

php

[RFC] [Vote] Readonly amendments

php.internals

Máté Kocsis

3 years ago

Hi Everyone,

We've just opened the vote for the "Readonly amendments" RFC, which is
going to be open for 2 weeks (until 2023-02-07).

Link: https://wiki.php.net/rfc/readonly_amendments
Discussion: https://externals.io/message/119007

Regards,
Máté Kocsis

Christian Schneider

3 years ago

Am 24.01.2023 um 09:55 schrieb Máté Kocsis <kocsismate90@gmail.com>:

> We've just opened the vote for the "Readonly amendments" RFC, which is
> going to be open for 2 weeks (until 2023-02-07).
>
> Link: https://wiki.php.net/rfc/readonly_amendments
> Discussion: https://externals.io/message/119007

I like the idea of more power to developers (even if they can shoot themselves in the foot), so I'm supporting this RFC.

While reading the example "Here is an example of a non-readonly child class that tracks the number of times a method has been called ... Such constructs are commonly used in e.g. mock classes ..." I was wondering why the same argument isn't applicable to most classes recently proposed as 'final', e.g. Text or Dequeue.

I know that there is the school of thought that "inheritance is bad" which discourages extending existing classes but I'm still not fully convinced something like benchmarking, logging or mocking are not valid applications of inheritance. Discouraging inheritance is one thing, disallowing another.

Maybe this needs to go to a separate thread but this RFC made me aware of this issue (and the different views people have about where PHP should go) again.

Regards,
- Chris

Matthew Weier O'Phinney

3 years ago

On Tue, Jan 24, 2023 at 2:55 AM Máté Kocsis <kocsismate90@gmail.com> wrote:

> Hi Everyone,
>
> We've just opened the vote for the "Readonly amendments" RFC, which is
> going to be open for 2 weeks (until 2023-02-07).
>
> Link: https://wiki.php.net/rfc/readonly_amendments
> Discussion: https://externals.io/message/119007
>

I missed something when reviewing previously.

Under the Proposal 1 section is the following verbiage:

> readonly classes can declare neither static, nor untyped properties, no

matter if the declaration is done directly in the class or indirectly via a
trait (https://github.com/php/php-src/issues/9285). Under this RFC, their
non-readonly child classes would support them as any other child class does.

However, the example demonstrates neither static nor untyped properties. As
such, it's hard to understand what pattern you are trying to enable here.
Could you provide an example of a child class that uses static and/or
untyped properties, please? Basically trying to understand what this would
enable, and why.

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

Robert Landers

3 years ago

On Tue, Jan 24, 2023 at 3:27 PM Matthew Weier O'Phinney
<mweierophinney@gmail.com> wrote:

>
> On Tue, Jan 24, 2023 at 2:55 AM Máté Kocsis <kocsismate90@gmail.com> wrote:
>
> > Hi Everyone,
> >
> > We've just opened the vote for the "Readonly amendments" RFC, which is
> > going to be open for 2 weeks (until 2023-02-07).
> >
> > Link: https://wiki.php.net/rfc/readonly_amendments
> > Discussion: https://externals.io/message/119007
> >
>
> I missed something when reviewing previously.
>
> Under the Proposal 1 section is the following verbiage:
>
> > readonly classes can declare neither static, nor untyped properties, no
> matter if the declaration is done directly in the class or indirectly via a
> trait (https://github.com/php/php-src/issues/9285). Under this RFC, their
> non-readonly child classes would support them as any other child class does.
>
> However, the example demonstrates neither static nor untyped properties. As
> such, it's hard to understand what pattern you are trying to enable here.
> Could you provide an example of a child class that uses static and/or
> untyped properties, please? Basically trying to understand what this would
> enable, and why.
>
> --
> Matthew Weier O'Phinney
> mweierophinney@gmail.com
> https://mwop.net/
> he/him

Mocking

Matthew Weier O'Phinney

3 years ago

On Tue, Jan 24, 2023 at 9:13 AM Robert Landers <landers.robert@gmail.com>
wrote:

> On Tue, Jan 24, 2023 at 3:27 PM Matthew Weier O'Phinney
> <mweierophinney@gmail.com> wrote:
> >
> > On Tue, Jan 24, 2023 at 2:55 AM Máté Kocsis <kocsismate90@gmail.com>
> wrote:
> >
> > > Hi Everyone,
> > >
> > > We've just opened the vote for the "Readonly amendments" RFC, which is
> > > going to be open for 2 weeks (until 2023-02-07).
> > >
> > > Link: https://wiki.php.net/rfc/readonly_amendments
> > > Discussion: https://externals.io/message/119007
> > >
> >
> > I missed something when reviewing previously.
> >
> > Under the Proposal 1 section is the following verbiage:
> >
> > > readonly classes can declare neither static, nor untyped properties, no
> > matter if the declaration is done directly in the class or indirectly
> via a
> > trait (https://github.com/php/php-src/issues/9285). Under this RFC,
> their
> > non-readonly child classes would support them as any other child class
> does.
> >
> > However, the example demonstrates neither static nor untyped properties.
> As
> > such, it's hard to understand what pattern you are trying to enable here.
> > Could you provide an example of a child class that uses static and/or
> > untyped properties, please? Basically trying to understand what this
> would
> > enable, and why.
>
> Mocking
>

This isn't a terribly compelling argument. Readonly classes are typically
value objects; it's rare that you will mock them as they will be used as
messages or results, and you'll end up doing assertions against them — not
mocking them.

Anything else it would enable?

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

Deleu

3 years ago

> >
> > Mocking
> >
>
> This isn't a terribly compelling argument. Readonly classes are typically
> value objects; it's rare that you will mock them as they will be used as
> messages or results, and you'll end up doing assertions against them — not
> mocking them.
>
> Anything else it would enable?

If like me you have a lot of service-style classes with recursive autowired
DI, making them all readonly is a no-brainer and mocking some of them
sometimes make sense. I have no opinion in favor or against, but wanted to
point out that to me value objects are less likely to be readonly than
service classes, where mocking are common.

Nicolas Grekas

3 years ago

Hi Matthew,

> We've just opened the vote for the "Readonly amendments" RFC, which is
> > going to be open for 2 weeks (until 2023-02-07).
> >
> > Link: https://wiki.php.net/rfc/readonly_amendments
> > Discussion: https://externals.io/message/119007
> >
>
> I missed something when reviewing previously.
>
> Under the Proposal 1 section is the following verbiage:
>
> > readonly classes can declare neither static, nor untyped properties, no
> matter if the declaration is done directly in the class or indirectly via a
> trait (https://github.com/php/php-src/issues/9285). Under this RFC, their
> non-readonly child classes would support them as any other child class
> does.
>
> However, the example demonstrates neither static nor untyped properties. As
> such, it's hard to understand what pattern you are trying to enable here.
> Could you provide an example of a child class that uses static and/or
> untyped properties, please? Basically trying to understand what this would
> enable, and why.
>

We've added a few examples on the RFC that should help clarify.
Here is the link to the diff:

https://wiki.php.net/rfc/readonly_amendments?do=diff&rev2%5B0%5D=1674550446&rev2%5B1%5D=1674635113&difftype=sidebyside

And the link to the updated RFC of course:
https://wiki.php.net/rfc/readonly_amendments

Nicolas

Máté Kocsis

3 years ago

Hi Everyone,

The vote for the "Readonly amendments" RFC is closed with the following
results:

Proposal #1 (Non-readonly classes can extend readonly classes):
The proposal was declined with 7 yes and 12 no votes (37%).

Proposal #2 (Readonly properties can be reinitialized during cloning):
The proposal was accepted with 26 yes and 0 no votes (100%).

Thanks to everyone who participated in the discussion or in the vote.

Regards,
Máté Kocsis