Implement readonly properties

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.

[nikic]

RFC: https://wiki.php.net/rfc/readonly_properties_v2

[matthieu88160]

Hi all,
Shouldn't this feature be extended to the class constant rather than properties only?

[iluuu1994]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

[matthieu88160]

@matthieu88160 Constants are by definition readonly. Not sure how that would make sense. Also note that the mailing list is the primary tool for feedback when it comes to specification.

My bad, I was thinking modification was allowed.

[iluuu1994]

@nikic Here are two more tests for useful use-cases of overriding a readonly property:

--TEST--
Visibility can change in readonly property
--FILE--
<?phpclass A {
protected readonly int $prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
publicreadonlyint$prop;
}
$a = newA();
try {
var_dump($a->prop);
} catch (\Error$error) {
echo$error->getMessage() . "\n";
}
$b = newB();
var_dump($b->prop);
?>
--EXPECT--
Cannot access protected property A::$prop
int(42)

---

--TEST--
Can override readonly property with attributes
--FILE--
<?php
#[Attribute]
class FooAttribute {}
class A {
publicreadonlyint$prop;
publicfunction__construct() {
$this->prop = 42;
}
}
class B extends A {
#[FooAttribute]
publicreadonlyint$prop;
}
var_dump((newReflectionProperty(B::class, 'prop'))->getAttributes()[0]->newInstance());
?>
--EXPECT--
object(FooAttribute)#1 (0) {
}

[reyadkhan]

Method parameters can be readonly:
foo(readonly string $bar){}

[kolardavid]

Hey guys, I would like to add my few objections you might want to consider:

1. Personally, I would allow unset() on readonly property, which would unlock it for writing again. This can be done only in private scope and can be useful. It would then work as controlled lockable property within scope, which has knowledge about the object. Also it would be consistent with typed properties, which can be unset, which returns them back in state, where reading throws exception (in oppose to writing).
2. PHP is imho missing simple function to check if typed or readonly property is initialized, which might be harder to safely detect if reading/writing will throw an exception or is permitted. People usually use isset(), which gives false negative if typed/readonly is already set to explicit null. It would be probably helpful to add is_initialized() function. You can't even use property_exists() for this, since it returns (correctly) true for uninitialized properties.
3. I would personally vote for not using readonly keyword, rather use writeonce/immutable/locked. readonly imho does not describe the usage that well as the other. Also, I would reserve readonly for other purpose:
4. readonly would be imho much more useful for different scenario, where property is writable within private scope and readonly outside of private scope. Actually I believe I would use this scenario even more than the currently proposed readonly feature. It would safely expose private properties to outside without risk of modification. It would be basically syntactic sugar for private property and public getter without setter (the above proposed behavior of being able to unset and set it again would be more close to this scenario, even though it would always require unset before set to be safe, which is annoying). I can imagine 2 ways of behavior:
   a. private readonly int $prop; would mean that property is writable in private scope and readonly in protected and public scope (in which case public readonly would be non-practical).
   b. public readonly int $prop; would mean the same, but changes meaning of visibility specifier (in which case private readonly would be non-practical)
   Basically the only difference would be if private/protected/public would specify where is readonly visible and it would be always writable only in private scope (which would work similarly to current readonly behavior, but you will be unable to make it writable from protected scope) or it would be always publicly visible, but you would specify if it is writable in private/protected/public scope. That would be imho more practical, but would be confusing and required explanation, because it would make visibility modifiers works differently than usual.

Of course there is option to merge both behaviors by adding modifier to readonly - so having public readonly working as readonly from outside, writable from inside and public readonly writeonce as current readonly proposal, making both things more consistent. The downside is that readonly writeonce is longer to write, but makes most sense to me.

Thank you for your attention and considering this opinions :)

[kocsismate]

Hey guys, I would like to add my few objections you might want to consider:

Please note that the feature is currently in voting, so any change should be warranted very much.

Points 3 and 4 have already been discussed to death, I believe the RFC provides background information why the readonly keyword (rather than writeonce) was chosen, and it also talks about the relation of "readonly properties" to the "asymmetric visibility" feature you also described.

Implementing an is_initialized() function could make sense, but it's IMO also orthogonal to this feature, since it doesn't only affect readonly properties. Also, it's already possible to detect if a property has been initialized via reflection.

Point 1 would render the feature broken, since any property value could be changed in private scope at any time, simply by unsetting it first.

[nikic]

is_initialized() was recently discussed and declined (https://externals.io/message/114607).

[kolardavid]

OK guys, thanks for your reply and sorry to bother you :)

[KalleZ]

Please keep these comments to the mailing list, the PR is not a forum for such

[rela589n]

Noted.

…

On Fri, Jul 16, 2021 at 9:28 AM Kalle Sommer Nielsen < ***@***.***> wrote: Please keep these comments to the mailing list, the PR is not a forum for such — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7089 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JVLQ7DVUE2BCE2EGBXLLTX7GRFANCNFSM456ZXYQQ> .

[jellynoone]

Hi, @nikic just tried this out, is it intentional that it's now possible to skip the public visibility modifer in promoted properties and regular readonly properties?

class ClassName
{
readonlyint$prop1;
function__construct(
readonly array $prop2,
) {
$this->prop1 = \count($prop2);
}
}
\var_dump(newClassName([1,2]));

[jrfnl]

Just FYI as I didn't see mention of the impact of readonly becoming a semi-reserved keyword in the potential for BC-breaks section of the RFC, nor a code-scan of top PHP projects to gauge the impact:
Global functions, classes et al named readonly will have to be renamed as this will now be a parse error.
And by extension, all calls to these functions/instantiations of these classes will have to be adjusted too as those will also be a parse error.

If nothing else, this affects WordPress - and by extension potentially all plugins and themes in its ecosphere. So far, the impact is estimated to be relatively small as the function (to add the readonly attribute to HTML input tags) is not that widely used, but still...

[iluuu1994]

Please use the mailing list for these discussions. The repercussions of a keyword are clear to voters. The suggestion of no $ was mentioned on the mailing list and not well received. While it avoids the BC break it's very subtle and doesn't communicate intent well. It's also way to late for this discussion in the first place. This RFC was in discussion for months.