Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Fri, 25 Nov 2022 at 00:07, Larry Garfield wrote: > > On Sun, Nov 20, 2022, at 7:20 AM, Dan Ackroyd wrote: > > Hi Larry, > > > > Regarding the syntax, up until now PHP has only supported the letters > > a-z and underscore in keywords. > > > > I realise this is an aesthetic thing, but

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi Robert On Thu, Jan 5, 2023 at 3:54 PM Robert Landers wrote: > > One quick question, > > Will changing the property of a protected/private set via reflection > be allowed? Or will you have to do some shenanigans like you currently > have to do with readonly? Since PHP 8.1

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

One quick question, Will changing the property of a protected/private set via reflection be allowed? Or will you have to do some shenanigans like you currently have to do with readonly? Robert Landers Software Engineer Utrecht NL On Wed, Jan 4, 2023 at 9:29 PM Larry Garfield wrote: > > On Wed,

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Wed, Dec 21, 2022, at 3:23 PM, Larry Garfield wrote: > On Tue, Dec 13, 2022, at 11:03 AM, Claude Pache wrote: >>> Le 13 déc. 2022 à 16:34, Claude Pache a écrit : >>> >>> >>> Hi, >>> >>> As of today, the following declarations are rejected as syntax errors: >>> >>> ```php >>> class C { >>>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Tue, Dec 13, 2022, at 11:03 AM, Claude Pache wrote: >> Le 13 déc. 2022 à 16:34, Claude Pache a écrit : >> >> >> Hi, >> >> As of today, the following declarations are rejected as syntax errors: >> >> ```php >> class C { >> $a; >> int $b; >> } >> ``` >> >> while the following

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> Le 13 déc. 2022 à 16:34, Claude Pache a écrit : > > > Hi, > > As of today, the following declarations are rejected as syntax errors: > > ```php > class C { > $a; > int $b; > } > ``` > > while the following declarations are accepted with implicit `public` > visibility: > >

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> Le 11 déc. 2022 à 20:18, Larry Garfield a écrit : > > On Thu, Dec 1, 2022, at 12:31 PM, Tim Düsterhus wrote: >> Hi >> >> On 11/29/22 21:29, Larry Garfield wrote: >>> Thank you everyone for the feedback. Based on this thread, we've made two >>> changes to the RFC: >>> >>> 1. We've moved

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 12 Dec 2022, at 02:18, Larry Garfield wrote: > > On Thu, Dec 1, 2022, at 12:31 PM, Tim Düsterhus wrote: >> Hi >> >> On 11/29/22 21:29, Larry Garfield wrote: >>> Thank you everyone for the feedback. Based on this thread, we've made two >>> changes to the RFC: >>> >>> 1. We've moved

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Thu, Dec 1, 2022, at 12:31 PM, Tim Düsterhus wrote: > Hi > > On 11/29/22 21:29, Larry Garfield wrote: >> Thank you everyone for the feedback. Based on this thread, we've made two >> changes to the RFC: >> >> 1. We've moved readonly back to forbidden with a-viz for now. I've added a >>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Mon, Dec 5, 2022, at 12:47 PM, Claude Pache wrote: >> Le 3 déc. 2022 à 19:28, Larry Garfield a écrit : >> >> I also clarified that static properties are explicitly not supported with >> a-viz. > > This is a serious issue, not necessarily because it is of great value, > but because it

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> Le 3 déc. 2022 à 19:28, Larry Garfield a écrit : > > I also clarified that static properties are explicitly not supported with > a-viz. This is a serious issue, not necessarily because it is of great value, but because it introduces an unexpected asymmetry between static and non-static

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Fri, Dec 2, 2022, at 7:11 AM, Stephen Reay wrote: > The proposed __set behaviour in this RFC will mean the second example > **won’t work**, and that is both extremely unintuitive and IMO, > technically unnecessary with regards to avoiding BC breaks. > > Cheers > > Stephen Thanks to the

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 2 Dec 2022, at 18:31, Ilija Tovilo wrote: > > Hi Stephen > >> So here’s my last attempt: >> >> Please change this behaviour in your rfc. >> >> You are explicitly making it mutually exclusive with readonly now, so that’s >> not a bc break - if/when it becomes compatible with readonly

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Le ven. 2 déc. 2022 à 12:32, Ilija Tovilo a écrit : > Hi Stephen > > > So here’s my last attempt: > > > > Please change this behaviour in your rfc. > > > > You are explicitly making it mutually exclusive with readonly now, so > that’s not a bc break - if/when it becomes compatible with readonly

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi Stephen > So here’s my last attempt: > > Please change this behaviour in your rfc. > > You are explicitly making it mutually exclusive with readonly now, so that’s > not a bc break - if/when it becomes compatible with readonly the authors of > that rfc can either keep the limitation as it

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 2 Dec 2022, at 01:21, Larry Garfield wrote: > > On Wed, Nov 30, 2022, at 7:38 PM, Stephen Reay wrote: > So please, can you explain to me why consistency with an implementation detail of readonly properties is more important than consistency with declared developer

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi On 11/29/22 21:29, Larry Garfield wrote: Thank you everyone for the feedback. Based on this thread, we've made two changes to the RFC: 1. We've moved readonly back to forbidden with a-viz for now. I've added a section to Future Scope where we really should sort this out in the future,

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Wed, Nov 30, 2022, at 7:38 PM, Stephen Reay wrote: >>> So please, can you explain to me why consistency with an implementation >>> detail of readonly properties is more important than consistency with >>> declared developer intention for regular properties via the magic >>> setter method?

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 1 Dec 2022, at 08:38, Stephen Reay wrote: > > > >> On 30 Nov 2022, at 22:09, Larry Garfield wrote: >> >> On Tue, Nov 29, 2022, at 11:25 PM, Stephen Reay wrote: >> >>> Hi Larry, >>> >>> Thank you for clarifying the setter behaviour in more explicit terms, >>> but I have to say I’m

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 30 Nov 2022, at 22:09, Larry Garfield wrote: > > On Tue, Nov 29, 2022, at 11:25 PM, Stephen Reay wrote: > >> Hi Larry, >> >> Thank you for clarifying the setter behaviour in more explicit terms, >> but I have to say I’m quite disappointed in this continued “use the >> logic of

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Wed, Nov 30, 2022, at 12:10 PM, Claude Pache wrote: > Hi, > > What is the behaviour of the following code? > > ```php > class Foo { > public private(set) array $bar = [ ]; > } > > $foo = new Foo; > > $foo->bar['x'] = 'y'; // error? > > var_dump(isset($foo->bar['x'])); // true?, false? > ```

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi, What is the behaviour of the following code? ```php class Foo { public private(set) array $bar = [ ]; } $foo = new Foo; $foo->bar['x'] = 'y'; // error? var_dump(isset($foo->bar['x'])); // true?, false? ``` I think that modification of an array should require write access? (That

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Tue, Nov 29, 2022, at 2:29 PM, Larry Garfield wrote: > On Sun, Nov 13, 2022, at 2:08 PM, Larry Garfield wrote: >> Hi folks. Ilija is nearly done with the implementation for asymmetric >> visibility and flushing out edge cases, but we've run into one design >> question we'd like feedback on.

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Tue, Nov 29, 2022, at 11:25 PM, Stephen Reay wrote: > Hi Larry, > > Thank you for clarifying the setter behaviour in more explicit terms, > but I have to say I’m quite disappointed in this continued “use the > logic of readonly to apply to something that is explicitly not > readonly” - this

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Wed, Nov 30, 2022, at 4:02 AM, Claude Pache wrote: >> Le 30 nov. 2022 à 02:27, Larry Garfield a écrit : >> >> On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote: >> >>> In the RFC, section Permitted visibility >>> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility >>>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> Le 30 nov. 2022 à 02:27, Larry Garfield a écrit : > > On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote: > >> In the RFC, section Permitted visibility >> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility >>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 30 Nov 2022, at 15:41, Alexandru Pătrănescu wrote: > > > On Wed, Nov 30, 2022, 05:25 Stephen Reay > wrote: > > > > On 30 Nov 2022, at 08:27, Larry Garfield > > wrote: > > > > On Tue, Nov 29, 2022, at 5:46 PM, Claude

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Wed, Nov 30, 2022, 05:25 Stephen Reay wrote: > > > > On 30 Nov 2022, at 08:27, Larry Garfield wrote: > > > > On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote: > > > >> In the RFC, section Permitted visibility > >> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility > >>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 30 Nov 2022, at 08:27, Larry Garfield wrote: > > On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote: > >> In the RFC, section Permitted visibility >> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility >>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote: > In the RFC, section Permitted visibility > (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility > ): >> The set visibility, if it differs from the main

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> Le 29 nov. 2022 à 21:29, Larry Garfield a écrit : > > > Thank you everyone for the feedback. Based on this thread, we've made two > changes to the RFC: > > 1. We've moved readonly back to forbidden with a-viz for now. I've added a > section to Future Scope where we really should sort

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, Nov 13, 2022, at 2:08 PM, Larry Garfield wrote: > Hi folks. Ilija is nearly done with the implementation for asymmetric > visibility and flushing out edge cases, but we've run into one design > question we'd like feedback on. > > There's two design decisions we've made at this point,

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, Nov 20, 2022, at 7:20 AM, Dan Ackroyd wrote: > Hi Larry, > > Regarding the syntax, up until now PHP has only supported the letters > a-z and underscore in keywords. > > I realise this is an aesthetic thing, but "private(set)" looks like a > function to me, and not a keyword. I saw the

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Tue, Nov 22, 2022, at 12:08 PM, Tim Düsterhus wrote: > Hi > > On 11/14/22 21:02, Claude Pache wrote: >> To clarify my position: >> >> * The set visibility must be either more restrictive or of the same >> restriction level than the get visibility. >> >> * When the set visibility is absent,

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi On 11/14/22 21:02, Claude Pache wrote: To clarify my position: * The set visibility must be either more restrictive or of the same restriction level than the get visibility. * When the set visibility is absent, it is inferred as following: * If `readonly` is present, the set

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On 20/11/2022 13:20, Dan Ackroyd wrote: This is getting quite complicated. I think unless someone makes a strong case for allowing the combination of the two, disallowing them being combined is probably the best choice. I'm inclined to agree. There's going to be a lot to understand and agree

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi Larry, Regarding the syntax, up until now PHP has only supported the letters a-z and underscore in keywords. I realise this is an aesthetic thing, but "private(set)" looks like a function to me, and not a keyword. I saw the previous poll, and it didn't include options for either

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Mon, 14 Nov 2022, Ilija Tovilo wrote: > Hi Derick > > > > As I understand it, you’re suggesting that a property declared as > > > `public protected(set)` would never trigger __set(). > > > > I would think that that would be against our current practice, which is > > easy enough to explain as

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

>> >> 1. Relax the set-is-tighter restriction. That would allow `protected >> protected(set)` etc. on any property. It wouldn't be particularly useful >> unless readonly is being used, but it would be syntactically legal and >> behave as you'd expect. We could still disallow "set is more

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, Nov 13, 2022, at 4:08 PM, Deleu wrote: >> >> >> This is untrue. You can declare a private property identically in a >> parent and child class, even readonly. I'm doing this now in a project. >> It works, but would be unnecessary if the parent's property were >> protected(set). >> >>

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi Derick > > As I understand it, you’re suggesting that a property declared as > > `public protected(set)` would never trigger __set(). > > I would think that that would be against our current practice, which is > easy enough to explain as "if the property isn't visible set, > then use __set()".

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Mon, 14 Nov 2022, Stephen Reay wrote: > As I understand it, you’re suggesting that a property declared as > `public protected(set)` would never trigger __set(). I would think that that would be against our current practice, which is easy enough to explain as "if the property isn't visible

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, 13 Nov 2022, Larry Garfield wrote: > There's two design decisions we've made at this point, both of which > we think are logical and reasonable: > > 1. If specified, the set visibility must be tighter than the get > visibility. So `protected protected(set)` and `protected public(set)`

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> On 14 Nov 2022, at 03:08, Larry Garfield wrote: > > Hi folks. Ilija is nearly done with the implementation for asymmetric > visibility and flushing out edge cases, but we've run into one design > question we'd like feedback on. > > There's two design decisions we've made at this point,

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> > public public(set) readonly string $foo > > protected protected(set) readonly string $foo > > These would be the only way to have a non-private-set readonly property. > While the first is in practice quite unlikely, the second has valid use > cases. Both have use cases. Whether

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, Nov 13, 2022 at 5:09 PM Larry Garfield wrote: > Hi folks. Ilija is nearly done with the implementation for asymmetric > visibility and flushing out edge cases, but we've run into one design > question we'd like feedback on. > > There's two design decisions we've made at this point, both

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> > > This is untrue. You can declare a private property identically in a > parent and child class, even readonly. I'm doing this now in a project. > It works, but would be unnecessary if the parent's property were > protected(set). > > --Larry Garfield > I do understand the slight complexity

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, Nov 13, 2022, at 3:50 PM, Deleu wrote: >> >> >> 2. `readonly` is a "write once" flag that may be combined with asymmetric >> visibility. If no set visibility is specified, `readoly` implies >> `private(set)`, but a different set visibility may also be provided. >> >> These are both

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

> > > 2. `readonly` is a "write once" flag that may be combined with asymmetric > visibility. If no set visibility is specified, `readoly` implies > `private(set)`, but a different set visibility may also be provided. > > These are both reasonable rules. However, it creates a conflict. >

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

On Sun, Nov 13, 2022, at 2:08 PM, Larry Garfield wrote: > Hi folks. Ilija is nearly done with the implementation for asymmetric > visibility and flushing out edge cases, but we've run into one design > question we'd like feedback on. > > There's two design decisions we've made at this point,

[PHP-DEV] [RFC] Asymmetric Visibility, with readonly

Hi folks. Ilija is nearly done with the implementation for asymmetric visibility and flushing out edge cases, but we've run into one design question we'd like feedback on. There's two design decisions we've made at this point, both of which we think are logical and reasonable: 1. If