Everything

php

Home » Project » Newsgroups » php.internals » Readonly properties - immutability by default »

Readonly properties - immutability by default

php.internals

[ ]

5 years ago

This is replica of github PR comments:

Hi there!
Isn't it better to simplify this a bit? I mean `readonly` keyword is really
long to type every time we need such property. Earlier (in php7.3)
properties were defined only with visibility modifier. Now it is going to
become *toooo verbose*.

```php
class A
{
// 24 characters before actual property name
readonly public string $name;
readonly public string $another;

public function __construct(string $var)
{
$this->name = $var;
$this->another = $var;
}
}

$a = new A('foo');
var_dump($a);
```

What seems for me to be better is remove `readonly` modifier at all, with
somewhat different modification. Look at the code below. This is intended
to work the same way as previous example.

```php
class A
{
// 14 characters before actual property name
public string name;
public string another;

public function __construct(string $var)
{
$this->name = $var;
$this->another = $var;
}
}

$a = new A('foo');
var_dump($a);
```

This is less explicit (we don't actually write `readonly` keyword), and it
may be confusing for some programmer who is new to php. However after first
attempt of modification, such layman will understand it's syntax and keep
with it.

Readonly properties are really useful for DDD, where everything is going to
be immutable. It promotes best practices. However for people to use it,
syntax should be concise and brief.

@nikic , want to hear your thoughts on this.

* kolardavid <https://github.com/kolardavid> * 1 hour ago
<https://github.com/php/php-src/pull/7089#issuecomment-881191365>

@rela589n <https://github.com/rela589n> First of all, you are coming late
(as me before), since this RFC is already voted and implemented completely.
Anyway, I find your suggestion bad. The truth is, that it is a bit more
verbose, but I am OK with that. It might be annoying to write (word
protected is even longer) but it is far better to read. It makes the code
more clear. Human brain is very well "optimized" to notice words it is used
to, more than symbols. This idea stays behind the fact that Delphi for
example uses begin/end instead of { and } (even though I am kind of tired
of it as well). Anyway, your solution of dropping $ for readonly property
would be nightmare for everyone, not just beginners. I am sure that @nikic
<https://github.com/nikic> will say the same, since he seems as pedantic as
I am about these things. Since all modifiers are already nice
self-explaining word, there is no point in doing this differently for new
modifier. It wouldn't be consistent, nor convenient. Mixed properties with
and without $ sign would look like typo, not intention.

* rela589n <https://github.com/rela589n> * 26 minutes ago
<https://github.com/php/php-src/pull/7089#issuecomment-881206048>
The philosophy of the Functional Programming <
http://en.wikipedia.org/wiki/Functional_programming> paradigm is strongly
geared towards all "variables" being immutable, and "mutable" ones being
only allowed in extreme cases (ie, for I/O. This will not look like a typo.
Immutability should be provided by default. BTW, in future scope we can
create "readonly" variables. So that once a variable is defined, no one can
change its value. I oppose creating kind of `let` and `const` for this.

* rela589n <https://github.com/rela589n> * 21 minutes ago
<https://github.com/php/php-src/pull/7089#issuecomment-881208237>

> Anyway, your solution of dropping $ for readonly property would be

nightmare for everyone, not just beginners

It would be a nightmare if these values could be changed. As we can't
rewrite `readonly` property, it looks like a constant. This concept of
readonly properties should come along with constants not only by semantics,
but also by syntax.

* rela589n <https://github.com/rela589n> * 18 minutes ago
<https://github.com/php/php-src/pull/7089#issuecomment-881209502>

> The truth is, that it is a bit more verbose, but I am OK with that. It

might be annoying to write (word protected is even longer) but it is far
better to read.

We already have Java with it's verbose syntax. We should think what should
be default and safe behaviour covering most cases and make such verbose
constructions for cases not covered by default logic.

Nikita Popov

5 years ago

On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> wrote:

> This is replica of github PR comments:
>
> Hi there!
> Isn't it better to simplify this a bit? I mean `readonly` keyword is really
> long to type every time we need such property. Earlier (in php7.3)
> properties were defined only with visibility modifier. Now it is going to
> become *toooo verbose*.
>
> ```php
> class A
> {
>     // 24 characters before actual property name
>     readonly public string $name;
>     readonly public string $another;
>
>     public function __construct(string $var)
>     {
>         $this->name = $var;
>         $this->another = $var;
>     }
> }
>
> $a = new A('foo');
> var_dump($a);
> ```
>
> What seems for me to be better is remove `readonly` modifier at all, with
> somewhat different modification. Look at the code below. This is intended
> to work the same way as previous example.
>
> ```php
> class A
> {
>     // 14 characters before actual property name
>     public string name;
>     public string another;
>
>     public function __construct(string $var)
>     {
>         $this->name = $var;
>         $this->another = $var;
>     }
> }
>
> $a = new A('foo');
> var_dump($a);
> ```
>
> This is less explicit (we don't actually write `readonly` keyword), and it
> may be confusing for some programmer who is new to php. However after first
> attempt of modification, such layman will understand it's syntax and keep
> with it.
>
> Readonly properties are really useful for DDD, where everything is going to
> be immutable. It promotes best practices. However for people to use it,
> syntax should be concise and brief.
>
> @nikic , want to hear your thoughts on this.
>
> * kolardavid <https://github.com/kolardavid> * 1 hour ago
> <https://github.com/php/php-src/pull/7089#issuecomment-881191365>
>
> @rela589n <https://github.com/rela589n> First of all, you are coming late
> (as me before), since this RFC is already voted and implemented completely.
> Anyway, I find your suggestion bad. The truth is, that it is a bit more
> verbose, but I am OK with that. It might be annoying to write (word
> protected is even longer) but it is far better to read. It makes the code
> more clear. Human brain is very well "optimized" to notice words it is used
> to, more than symbols. This idea stays behind the fact that Delphi for
> example uses begin/end instead of { and } (even though I am kind of tired
> of it as well). Anyway, your solution of dropping $ for readonly property
> would be nightmare for everyone, not just beginners. I am sure that @nikic
> <https://github.com/nikic> will say the same, since he seems as pedantic
> as
> I am about these things. Since all modifiers are already nice
> self-explaining word, there is no point in doing this differently for new
> modifier. It wouldn't be consistent, nor convenient. Mixed properties with
> and without $ sign would look like typo, not intention.
>
> * rela589n <https://github.com/rela589n> * 26 minutes ago
> <https://github.com/php/php-src/pull/7089#issuecomment-881206048>
> The philosophy of the Functional Programming <
> http://en.wikipedia.org/wiki/Functional_programming> paradigm is strongly
> geared towards all "variables" being immutable, and "mutable" ones being
> only allowed in extreme cases (ie, for I/O. This will not look like a typo.
> Immutability should be provided by default. BTW, in future scope we can
> create "readonly" variables. So that once a variable is defined, no one can
> change its value. I oppose creating kind of `let` and `const` for this.
>
> * rela589n <https://github.com/rela589n> * 21 minutes ago
> <https://github.com/php/php-src/pull/7089#issuecomment-881208237>
> > Anyway, your solution of dropping $ for readonly property would be
> nightmare for everyone, not just beginners
>
> It would be a nightmare if these values could be changed. As we can't
> rewrite `readonly` property, it looks like a constant. This concept of
> readonly properties should come along with constants not only by semantics,
> but also by syntax.
>
> * rela589n <https://github.com/rela589n> * 18 minutes ago
> <https://github.com/php/php-src/pull/7089#issuecomment-881209502>
> > The truth is, that it is a bit more verbose, but I am OK with that. It
> might be annoying to write (word protected is even longer) but it is far
> better to read.
>
> We already have Java with it's verbose syntax. We should think what should
> be default and safe behaviour covering most cases and make such verbose
> constructions for cases not covered by default logic.
>

We cannot make properties readonly by default, because that would be a
major backwards compatibility break.

If you're going for brevity, something you can do is omit the visibility
specifier, as it is public by default. "readonly int $prop" works.

Regards,
Nikita

[ ]

5 years ago

Thanks for your response!
Anyway, I probably put it wrong by saying "by default", so let me clarify
myself.

What I really mean is omitting the dollar sign. So everything remains the
same with ordinary properties (which are mutable), and we introduce
immutable (readonly) properties as another type of them.
It looks like a great default:
```php
public string name;
```

So, once again, it has nothing to do with backward compatibility. No one
disposes the way properties are currently working. We introduce a new
_type_ or _kind_ of properties - readonly.

Also I see useful future scope like readonly parameters:

```php
function foo(int firstParam, bool secondParam)
{
// no way to modify it, Error
firstParam = 23 * secondParam;

return firstParam * secondParam;
}
```

Yes, we can implement this with another keyword (again, `readonly`), but as
I see, only few people will use it because it is too complicated (really,
instead of simply declaring an argument, a programmer has to write a bunch
of other stuff in front of it for every single method and function).


On Fri, Jul 16, 2021 at 10:06 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

Pierre

5 years ago

Le 16/07/2021 à 10:11, Eugene Sidelnyk a écrit :

> Thanks for your response!
> Anyway, I probably put it wrong by saying "by default", so let me clarify
> myself.
>
> What I really mean is omitting the dollar sign. So everything remains the
> same with ordinary properties (which are mutable), and we introduce
> immutable (readonly) properties as another type of them.
> It looks like a great default:
> ```php
>      public string name;
> ```
>
> So, once again, it has nothing to do with backward compatibility. No one
> disposes the way properties are currently working. We introduce a new
> _type_ or _kind_ of properties - readonly.
>
> Also I see useful future scope like readonly parameters:
>
> ```php
> function foo(int firstParam, bool secondParam)
> {
>    // no way to modify it, Error
>    firstParam = 23 * secondParam;
>
>    return firstParam * secondParam;
> }
> ```
>
> Yes, we can implement this with another keyword (again, `readonly`), but as
> I see, only few people will use it because it is too complicated (really,
> instead of simply declaring an argument, a programmer has to write a bunch
> of other stuff in front of it for every single method and function).

Hello,

I'm very happy that the readonly properties RFC did pass, I waited for
this for a long time.

I like the "readonly" explicit keyword, explicit is always better than
implicit for disambiguation and readability. I'd wish having per-default
readonly properties as well, but this is PHP and fundamentals cannot be
changed just like that, it's not Rust, or any other language, PHP is PHP.

Explicit "readonly" is in my opinion the best option, it's easy to type,
and it's easy to read, and it's the same keyword in many other
languages. On the opposite side, omiting the $ sign seems like a huge
mind-fuck, easy to miss-read, easy to miss-type, error prone and obscure.

Regards,

--

Pierre

AllenJB

5 years ago

On 16/07/2021 09:11, Eugene Sidelnyk wrote:

> Thanks for your response!
> Anyway, I probably put it wrong by saying "by default", so let me clarify
> myself.
>
> What I really mean is omitting the dollar sign. So everything remains the
> same with ordinary properties (which are mutable), and we introduce
> immutable (readonly) properties as another type of them.
> It looks like a great default:
> ```php
>      public string name;
> ```
>
> So, once again, it has nothing to do with backward compatibility. No one
> disposes the way properties are currently working. We introduce a new
> _type_ or _kind_ of properties - readonly.
>
> Also I see useful future scope like readonly parameters:
>
> ```php
> function foo(int firstParam, bool secondParam)
> {
>    // no way to modify it, Error
>    firstParam = 23 * secondParam;
>
>    return firstParam * secondParam;
> }
> ```
>
> Yes, we can implement this with another keyword (again, `readonly`), but as
> I see, only few people will use it because it is too complicated (really,
> instead of simply declaring an argument, a programmer has to write a bunch
> of other stuff in front of it for every single method and function).

I do not like this suggestion because it's too subtle / non-obvious.
Think from the point of view of an inexperienced developer who is
reading through code and they come across this. What does it mean?
What's different about it? They might not even notice the subtle
different to other parameters, then get frustrated when the changes
they've made don't work and they have to waste time going back to redo them.

The readonly keyword in front of properties is clear. Without even
reading the manual a new developer coming across this for the first time
will have some idea of how they can expect it to work / how it should be
used.

I think that your "future scope" of readonly variables using the same no
$ format likely has problems with constants and keywords. This would
cause more problems when new keywords are added to the language. Even if
the language itself doesn't have problems, I think it could
significantly affect the readability of code in many cases.

I think that a better suggestion would be to offer 'ro' as an
(additional) alternative to 'readonly'. It's still shorter and I think
that its meaning is likely to be understood / guessable by a significant
proportion of (even inexperienced) developers.

Nikita Popov

5 years ago

On Fri, Jul 16, 2021 at 10:11 AM Eugene Sidelnyk <zsidelnik@gmail.com>
wrote:

> Thanks for your response!
> Anyway, I probably put it wrong by saying "by default", so let me clarify
> myself.
>
> What I really mean is omitting the dollar sign. So everything remains the
> same with ordinary properties (which are mutable), and we introduce
> immutable (readonly) properties as another type of them.
> It looks like a great default:
> ```php
>     public string name;
> ```
>

Ah, I see. I didn't get that the missing dollar sign is a relevant part of
the example, I thought it was just a typo.

I can't say I like this proposal, because it's very subtle. "public string
$name" is a mutable property, "public string name" is immutable. I can kind
of see where you're coming from here, given how generally "foo" in PHP
refers to immutable symbols like constants, functions or classes, while
"$foo" refers to a mutable symbol. But that's something that applies to use
of the symbol. We're always explicit at the declaration site, it's const
FOO, function foo, class Foo etc. Here mutability is decided by single $
character in the declaration, which doesn't have a particular obvious
connection to mutability.

Regards,
Nikita

Andreas Leathley

5 years ago

On 16.07.21 09:06, Nikita Popov wrote:

> We cannot make properties readonly by default, because that would be a
> major backwards compatibility break.
>
> If you're going for brevity, something you can do is omit the visibility
> specifier, as it is public by default. "readonly int $prop" works.

Would it be possible to adapt constructor property promotion to support
this (as far as I tell, it currently does not)? Namely:

class A {
    public function __construct(
        readonly int $id,
    ) {
    }
}

According to the constructor property promotion RFC, the promotion only
happens when public, private and protected is used for an constructor
parameter. With the readonly RFC accepted, it would make sense to also
do constructor property promotion when readonly is used, to avoid the
explicit public, because readonly would also clearly define the
parameter as not-only-a-parameter.

[ ]

5 years ago

I don't think the way it is going to be realeased is elegant solution

On Sat, Jul 17, 2021, 2:47 PM Andreas Leathley <a.leathley@gmx.net> wrote:

Weirdan

5 years ago

On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> wrote:

> Readonly properties are really useful for DDD, where everything is going to
> be immutable. It promotes best practices. However for people to use it,
> syntax should be concise and brief.

If every property of the class is readonly it would probably be better
to declare that with a class modifier.

E.g.

```php
readonly class Entity {
public int $count;
public string $data;
}
```

Though `readonly` doesn't look like a perfect fit in that position to me.

--
Best regards,
Bruce Weirdan                                     mailto:weirdan@gmail.com

[ ]

5 years ago

@Nikita Popov <nikita.ppv@gmail.com> I'm not sure what you mean by saying
this:

> We're always explicit at the declaration site, it's const FOO, function

foo, class Foo etc

Regarding your message

>  Here mutability is decided by single $ character in the declaration,

which doesn't have a particular obvious connection to mutability.

Yes, that is not really obvious about property mutability when we look at
the code.
I think it is probably better to rephrase it into something like: New way
of properties definition without dollar sign. Not only do we remove dollar
sign, but these properties can not be reassigned.

Looking from this perspective we are trying to improve code quality and
developer experience. Using immutability (as well as type-hints with strict
typing)  makes code less error prone. This should be promoted in the PHP
community.
What I want to say is: good things should be easily done, easier than
things which are more error prone.

Again, about explicitness and obviousness.
Imagine (just for a second) that all existing properties are immutable by
default. Then someone submits RFC to add mutability for them. It is
accepted to add a new keyword like this:

```php
mutable public string $bar;
```

Hence I mean: currently we have one default option (mutable properties)
from 2 options. Why do we need to create such a long keyword just to use
readonly properties (if immutability is better than mutability)?

Regards, Eugene

On Fri, Jul 16, 2021 at 1:13 PM Bruce Weirdan <weirdan@gmail.com> wrote:

Larry Garfield

5 years ago

On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote:

> @Nikita Popov <nikita.ppv@gmail.com> I'm not sure what you mean by saying
> this:
>
> > We're always explicit at the declaration site, it's const FOO, function
> foo, class Foo etc
>
>
> Regarding your message
>
> >  Here mutability is decided by single $ character in the declaration,
> which doesn't have a particular obvious connection to mutability.
>
> Yes, that is not really obvious about property mutability when we look at
> the code.
> I think it is probably better to rephrase it into something like: New way
> of properties definition without dollar sign. Not only do we remove dollar
> sign, but these properties can not be reassigned.
>
> Looking from this perspective we are trying to improve code quality and
> developer experience. Using immutability (as well as type-hints with strict
> typing)  makes code less error prone. This should be promoted in the PHP
> community.
> What I want to say is: good things should be easily done, easier than
> things which are more error prone.
>
> Again, about explicitness and obviousness.
> Imagine (just for a second) that all existing properties are immutable by
> default. Then someone submits RFC to add mutability for them. It is
> accepted to add a new keyword like this:
>
> ```php
> mutable public string $bar;
> ```
>
> Hence I mean: currently we have one default option (mutable properties)
> from 2 options. Why do we need to create such a long keyword just to use
> readonly properties (if immutability is better than mutability)?
>
> Regards, Eugene

A) Please don't top post.  This is a bottom-post-centric list.

B) As others have said, if we were designing the language today we would do it very differently.  I'd likely push for following Rust's example of immutable by default, super strong typing, and a `mut` keyword to poke holes in the immutability where necessary.

However, we have ample existing code that cannot be broken, so that limits what we can do.  That means adding a readonly/immutable/whatever flag is the only real option, even if it is annoyingly verbose.

I can see the logic behind "initialize at runtime constants" which is what you're describing, as an alternative.  However, that breaks a ton of existing patterns.

1) Variables in PHP always begin with $.  For all time, Always.

2) Objects do not have constants.  Classes have constants.  Introducing object-level constants is potentially confusing.

3) Constants shouldn't be set even once.  Properties can be, but properties have $ on them.

3) What would reflection do with these object constants?  Are they still properties according to reflection, or are they something else?  Can I enumerate mutable properties and constant properties together or separately?  This gets complicated fast.

I agree with the point that the verbosity of `readonly` is potentially annoying, but we haven't seen it in practice yet.  If it ends up being a problem, then as someone else suggested a more likely solution is a `readonly` flag on the class, possibly with a `mut` keyword on the property to opt it back out, or something like that.  Not ideal, but probably the best we could do.

Having very subtly different syntax for a very significant behavioral difference in properties seems like a landmine waiting to happen that would only confuse people.

--Larry Garfield

[ ]

5 years ago

> Please don't top post.  This is a bottom-post-centric list.

Can you please tell me what mailing client you use and what should I?

> if we were designing the language today we would do it very differently.

This reminds me working with legacy code in the team which says to write
the code in the style in which the project is written.
You are trying to make your code more maintainable and readable, decompose
your functionality, define clear pre and post conditions.
Then comes time for code review and teamlead orders you to throw everything
away and write the same legacy as they do because project is written this
way.

PS. No more do I work in this team.

Can you please explain what prevents us from doing the best (like if we
were designing the language today) for new features now?

1) Dollars in PHP

> Variables in PHP always begin with $.  For all time, Always.

Yes, but let's not confuse variables (which by definition can be rewritten)
with values that can get it's value only once.
Almost every time we encounter $ sign in PHP, we can change it's value
either as a $property or $variable.
All the time we encounter "immutable descriptor for value" (fancy name for
not-variable) without dollar sign, it can't be changed. I am talking about
constants.

2) Object constants

> Objects do not have constants. Classes have constants.

Yes, objects do not have constants, but may have `readonly` properties
which use constant-like syntax because they can't be ever changed. I don't
understand why you name it constants if it is not.

> Introducing object-level constants is potentially confusing.

Yes, introducing constants may be confusing. Introduction of `readonly`
properties with dollarless syntax is very logical.

3) Constants and Properties

> Constants shouldn't be set even once.  Properties can be, but properties

have $ on them.

Again, dollar sign is used for mutable value descriptors.
Constants don't have dollar sign and are not overwritable.
Readonly properties should not have dollar sign because they are not
overwritable as well.

4) Reflection part doesn't seem to be complicated here

>  Are they still properties according to reflection, or are they something

else?

According to reflection, these are properties.

> What would reflection do with these object constants?

The reflection part should remain the same as it is with current RFC so
that `ReflectionProperty::isReadOnly` is added as well as `IS_READONLY`
flag added to the modifiers list.

> Can I enumerate mutable properties and constant properties together or

separately?

Why would you need to enumerate them separately? All of them are properties
by definition.

> Having very subtly different syntax for a very significant behavioral

difference in properties seems like a landmine waiting to happen that would
only confuse people.

We are in the programming world. In PHP if someone gets undermined, he will
know what he did wrong right in a few seconds. After blowing up (if this
will ever happen), programmer will write the code with understanding how
and why it works this way.



On Fri, Jul 16, 2021 at 7:14 PM Larry Garfield <larry@garfieldtech.com>
wrote:

Mike Schinkel

5 years ago

> On Jul 16, 2021, at 6:12 AM, Bruce Weirdan <weirdan@gmail.com> wrote:
>
> On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> wrote:
>
>> Readonly properties are really useful for DDD, where everything is going to
>> be immutable. It promotes best practices. However for people to use it,
>> syntax should be concise and brief.
>
> If every property of the class is readonly it would probably be better
> to declare that with a class modifier.
>
> E.g.
>
> ```php
> readonly class Entity {
>    public int $count;
>    public string $data;
> }
> ```

Having a "readonly" class where the properties are read-only by default makes sense to me, but maybe the better way to do it is with an attribute?

#[Readonly]
class Entity {
public int $count;
public string $data;
}

OTOH, that would be inconsistent with using `readonly` as a keyword for properties.

-Mike
P.S. Maybe readonly properties should be implemented with an attribute instead of a keyword?  But then that would be opening a can of worms...

[ ]

5 years ago

> Having a "readonly" class where the properties are read-only by default

makes sense to me, but maybe the better way to do it is with an attribute?

We already have such an attribute provided. It is called [`#[Immutable]`](
https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable
).
If the intention is to add some logic for attributes, then unlikely it is
going to be accepted because attributes by definition are meta-data. It
doesn't add any logic for program.


On Sat, Jul 17, 2021 at 12:09 AM Mike Schinkel <mike@newclarity.net> wrote:

Mike Schinkel

5 years ago

> On Jul 17, 2021, at 1:40 AM, Eugene Sidelnyk <zsidelnik@gmail.com> wrote:
>
> > Having a "readonly" class where the properties are read-only by default makes sense to me, but maybe the better way to do it is with an attribute?
>
> We already have such an attribute provided. It is called [`#[Immutable]`](https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable <https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable>).

Actually, you are confusing PhpStorm's inclusion of PhpStorm-specific userland attributes where the PhpStorm team are probably trying to drive defacto-standard meanings for those attributes they documents with attributes that has specific meanings and behavior recognized by PHP itself.

Nothing against PhpStorm — it is my IDE/editor of choice and I applaud JetBrain's leadership in this area — but their attributes are still just their attributes, not attributes defined by in a PHP RFC.

> If the intention is to add some logic for attributes, then unlikely it is going to be accepted because attributes by definition are meta-data. It doesn't add any logic for program.

Actually, that is not true either.  PHP already has one attribute that PHP itself recognizes, named "Attribute."  As Larry Garfield wrote[1]:  "The #[Attribute] attribute tells PHP “yes, this class can be loaded as an attribute.”

You can also see that future scope was explicitly envisioned[2] that some small number of attributes might potentially be more than just metadata.


-Mike
[1] https://platform.sh/blog/2020/php-8-0-feature-focus-attributes/ <https://platform.sh/blog/2020/php-8-0-feature-focus-attributes/>
[2] https://wiki.php.net/rfc/attributes_v2#future_scope <https://wiki.php.net/rfc/attributes_v2#future_scope>