Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Mon, Aug 5, 2024, at 7:27 AM, Vincent de Lau wrote: > From: Rob Landers > Sent: Sunday, July 21, 2024 11:21 AM > >> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: >> > On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: >> > > Will the alternative syntax on hook not even be put to a

RE: [PHP-DEV] [RFC] Asymmetric Visibility, v2

From: Rob Landers Sent: Sunday, July 21, 2024 11:21 AM > On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: > > On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: > > > Will the alternative syntax on hook not even be put to a vote? > > It was, a year and a half ago when Aviz was first p

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, Jul 26, 2024, at 16:27, Larry Garfield wrote: > On Fri, Jul 26, 2024, at 12:58 PM, Rob Landers wrote: > > >> And now that I see it spelled out more, I do agree that while it appears a > >> bit more verbose, and this "(set)" looks odd at first, having all the > >> visibility upfront is a

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, Jul 26, 2024, at 12:58 PM, Rob Landers wrote: >> And now that I see it spelled out more, I do agree that while it appears a >> bit more verbose, and this "(set)" looks odd at first, having all the >> visibility upfront is a lot clearer than having to read through the hooks to >> see wha

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, Jul 26, 2024, at 13:36, Jordi Boggiano wrote: > On 21.07.2024 11:21, Rob Landers wrote: >> >> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: >>> On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: >>> > Will the alternative syntax on hook not even be put to a vote? >>> >>> It

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On 21.07.2024 11:21, Rob Landers wrote: On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: > Will the alternative syntax on hook not even be put to a vote? It was, a year and a half ago when Aviz was first proposed.  The preference wa

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Mon, Jul 22, 2024, at 7:07 PM, Tim Düsterhus wrote: > Hi > > On 7/20/24 03:14, Larry Garfield wrote: >> Baring any new developments, we plan to start the vote early next week. > > I've went through the RFC once more. I have the following remarks: > >> For that reason, a private(set) property is

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi On 7/20/24 03:14, Larry Garfield wrote: Baring any new developments, we plan to start the vote early next week. I've went through the RFC once more. I have the following remarks: For that reason, a private(set) property is automatically final and may not be redeclared at all. I assume

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Sun, Jul 21, 2024, at 2:45 PM, Tim Düsterhus wrote: > Hi > > On 7/20/24 03:14, Larry Garfield wrote: >> We've made one change since we last discussed it: Specifically, Ilija >> realized that __set's behavior is already inconsistent, so supporting it for >> aviz properties with invisible set w

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi On 7/20/24 03:14, Larry Garfield wrote: We've made one change since we last discussed it: Specifically, Ilija realized that __set's behavior is already inconsistent, so supporting it for aviz properties with invisible set would make it even more inconsistent, not less. For that reason, w

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: > On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: > > Will the alternative syntax on hook not even be put to a vote? > > It was, a year and a half ago when Aviz was first proposed. The preference > was split, but leaned toward the p

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: > Will the alternative syntax on hook not even be put to a vote? It was, a year and a half ago when Aviz was first proposed. The preference was split, but leaned toward the prefix-style syntax. So we went with that. I don't think we'll e

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Sat, Jul 20, 2024, at 10:47 AM, Ilija Tovilo wrote: > Hi Rob > > On Sat, Jul 20, 2024 at 3:47 PM Rob Landers wrote: >> >> On Sat, Jul 20, 2024, at 03:14, Larry Garfield wrote: >> >> On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote: >> > >> > https://wiki.php.net/rfc/asymmetric-visibility-

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi Rob On Sat, Jul 20, 2024 at 3:47 PM Rob Landers wrote: > > On Sat, Jul 20, 2024, at 03:14, Larry Garfield wrote: > > On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote: > > > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > Hi folks. After a side quest to polish off hooks, we're ne

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Sat, Jul 20, 2024, at 03:14, Larry Garfield wrote: > On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote: > > As promised, Ilija and I offer this revised version of asymmetric > > visibility. > > > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > > > It's still essentially the same

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Will the alternative syntax on hook not even be put to a vote? I think the "prefix-style" syntax breaks the standard property signature template that exists since PHP 5! Natural syntax: $; With prefix-style: (set) $; This introduces a syntax that is totally unexpected to natural reading.

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote: > As promised, Ilija and I offer this revised version of asymmetric visibility. > > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > It's still essentially the same as last year's version, but with a few > adjustments and changes: >

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Yeah i know im just one irrelevant person with crazy ideas (stable engine etc). I never said PHP needs me, I simply decided to no longer be a part of this shithole. I mean i brought up valid points about the engine, yet here you are with a retarded cheeky response when you could've just ignored me.

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Tue, Jun 11, 2024, at 1:48 PM, Rob Landers wrote: > On Tue, Jun 11, 2024, at 15:36, Larry Garfield wrote: >> On Tue, Jun 11, 2024, at 6:47 AM, Rob Landers wrote: >> >> > I’m also not a fan of the prefix style, but for different reasons. My >> > main reason is that it increases the minimum line

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Tue, Jun 11, 2024, at 15:36, Larry Garfield wrote: > On Tue, Jun 11, 2024, at 6:47 AM, Rob Landers wrote: > > > I’m also not a fan of the prefix style, but for different reasons. My > > main reason is that it increases the minimum line-length, potentially > > forcing you to chop things down i

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Tue, Jun 11, 2024, at 6:47 AM, Rob Landers wrote: > I’m also not a fan of the prefix style, but for different reasons. My > main reason is that it increases the minimum line-length, potentially > forcing you to chop things down into awkward looking lines: > > public > private(set) > string $l

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Tue, Jun 11, 2024 at 3:15 AM Lanre wrote: > Why invest time in crafting yet another pull request or RFC when it's > glaringly obvious that you guys have no clue what you're doing? First, > there's the questionable decision to implement JIT in 8.0, followed by the > introduction of an entirely

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Mon, Jun 10, 2024, at 19:51, Rodrigo Vieira wrote: > I didn't like the `Prefix-style` syntax. I prefer the `Hook-embedded-style` > syntax. First let's look at the counterpoints of the `Prefix-style` syntax: > > ## 1) "`Prefix-style` is more visually scannable" > > The set visibility is 10 line

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Why invest time in crafting yet another pull request or RFC when it's glaringly obvious that you guys have no clue what you're doing? First, there's the questionable decision to implement JIT in 8.0, followed by the introduction of an entirely new library (IR) to a language that's predominantly req

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On 10 June 2024 21:17:38 BST, Lanre wrote: >You guys are killing PHP. There is a lot of work to be done on the engine >to modernize it and make it more robust and sturdy. Shit like this just >adds more complexity to PHP in the name of convenience. I think this is my >cue to explore other languages

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

You guys are killing PHP. There is a lot of work to be done on the engine to modernize it and make it more robust and sturdy. Shit like this just adds more complexity to PHP in the name of convenience. I think this is my cue to explore other languages for handling requests On Mon, Jun 10, 2024 at

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

I didn't like the `Prefix-style` syntax. I prefer the `Hook-embedded-style` syntax. First let's look at the counterpoints of the `Prefix-style` syntax: ## 1) "`Prefix-style` is more visually scannable" > The set visibility is 10 lines away from the get visibility! Solution: ```php class HookEmbe

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, May 29, 2024, 2:16 PM Larry Garfield wrote: > As promised, Ilija and I offer this revised version of asymmetric > visibility. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > It's still essentially the same as last year's version, but with a few > adjustments and changes: > > * r

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Sat, Jun 8, 2024, at 3:49 AM, Arvids Godjuks wrote: > On Fri, 7 Jun 2024 at 17:30, Larry Garfield wrote: >> On Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrote: >> > On Wed, 5 Jun 2024 at 19:59, Claude Pache wrote: >> > *snip* >> > Hello everyone, >> > I've been seeing readonly bashed/blamed

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, 7 Jun 2024 at 17:30, Larry Garfield wrote: > On Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrote: > > On Wed, 5 Jun 2024 at 19:59, Claude Pache > wrote: > > *snip* > > Hello everyone, > > I've been seeing readonly bashed/blamed/being roadblock, etc, etc as in > > the implementation end

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrote: > On Wed, 5 Jun 2024 at 19:59, Claude Pache wrote: >> *snip* >> Hi Larry and Ilija, >> >> Thanks for your work. Here is my opinion: >> >> First, I do think that `readonly` should integrate with aviz, unless that >> implies truly controversi

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi Tim On Tue, Jun 4, 2024 at 7:54 PM Tim Düsterhus wrote: > > One thing that would get pretty wonky would be private-read properties: > Private property names are currently internally "mangled" to include the > class name. This allows to define the same private property in multiple > classes of

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, 5 Jun 2024 at 19:59, Claude Pache wrote: > *snip* > Hi Larry and Ilija, > > Thanks for your work. Here is my opinion: > > First, I do think that `readonly` should integrate with aviz, unless that > implies truly controversial changes on `readonly`. As Theodore Brown > commented in the pre

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 5 juin 2024 à 16:28, Larry Garfield a écrit : > > On Fri, May 31, 2024, at 8:59 PM, Larry Garfield wrote: >> On Fri, May 31, 2024, at 5:45 PM, Claude Pache wrote: Le 31 mai 2024 à 18:08, Larry Garfield a écrit : However, this also brings up another interesting issue: reado

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, May 31, 2024, at 8:59 PM, Larry Garfield wrote: > On Fri, May 31, 2024, at 5:45 PM, Claude Pache wrote: >>> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : >>> >>> However, this also brings up another interesting issue: readonly properties >>> (in 8.3) DO allow redeclaration, essentiall

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi On 6/4/24 15:30, Larry Garfield wrote: If enough people felt strongly that it should be allowed, I don't think there's any technical reason it couldn't be allowed, other than it would allow some rather silly combinations. (Ilija can tell me if I'm wrong.) However, also note that it is, o

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Tue, Jun 4, 2024, at 5:01 AM, Andreas Heigl wrote: > There is only one thing that I stumbled upon which struck me as odd: > > > The set visibility, if specified explicitly, MUST be equal to or > > lesser than the main (get) visibility. That is, protected public(set) > > string $foo is not al

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hey Larry, hey Ilija Am 29.05.24 um 21:15 schrieb Larry Garfield: As promised, Ilija and I offer this revised version of asymmetric visibility. https://wiki.php.net/rfc/asymmetric-visibility-v2 It's still essentially the same as last year's version, but with a few adjustments and changes: *

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, May 31, 2024 at 7:13 PM Larry Garfield wrote: > > So we feel the best way forward is to make the following changes: > > * private(set) implicitly means "final". (You can declare it explicitly > if you want, but it isn't necessary.) > * Make readonly incompatible with aviz again. > > Thou

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> So we feel the best way forward is to make the following changes: > > * private(set) implicitly means "final". (You can declare it explicitly if you want, but it isn't necessary.) > * Make readonly incompatible with aviz again. I'd make readonly incompatible with aviz. Readonly props have its "

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : > > So we feel the best way forward is to make the following changes: > > * private(set) implicitly means "final". (You can declare it explicitly if > you want, but it isn't necessary.) > * Make readonly incompatible with aviz again. > > Th

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, May 31, 2024 at 9:13 PM Claude Pache wrote: > > > > Le 31 mai 2024 à 18:08, Larry Garfield a écrit : > > However, this also brings up another interesting issue: readonly properties > (in 8.3) DO allow redeclaration, essentially adjusting the property scope > (the class that declares it)

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, May 31, 2024, at 5:45 PM, Claude Pache wrote: >> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : >> >> However, this also brings up another interesting issue: readonly properties >> (in 8.3) DO allow redeclaration, essentially adjusting the property scope >> (the class that declares it

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : > > However, this also brings up another interesting issue: readonly properties > (in 8.3) DO allow redeclaration, essentially adjusting the property scope > (the class that declares it) to make the visibility check pass. That is, the > defi

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, May 31, 2024, at 12:04 PM, Alexandru Pătrănescu wrote: > On Fri, May 31, 2024 at 10:30 AM Claude Pache wrote: >> >> >>> Le 30 mai 2024 à 17:07, Derick Rethans a écrit : >>> Now, if I define the property as public private(set) with similar intentions, to make sure that

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 30 mai 2024 à 12:16, Vincent de Lau a écrit : > >> >> We went through a bunch of syntax variations last year, including "public >> private", "public:private", and "public private:set", plus a few others. >> In an RCV poll, public private(set) was the favorite. (See link at the end >> of t

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Fri, May 31, 2024 at 10:30 AM Claude Pache wrote: > > > Le 30 mai 2024 à 17:07, Derick Rethans a écrit : > > > Now, if I define the property as public private(set) with similar > intentions, to make sure that there is no way for external scope or > extending classes scope to write to the prop

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 30 mai 2024 à 17:07, Derick Rethans a écrit : > >> >> Now, if I define the property as public private(set) with similar >> intentions, to make sure that there is no way for external scope or >> extending classes scope to write to the property, while allowing >> reading from external sc

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Thu, 30 May 2024, Alexandru Pătrănescu wrote: > On Wed, May 29, 2024 at 10:18 PM Larry Garfield > wrote: > > > As promised, Ilija and I offer this revised version of asymmetric > > visibility. > > > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > > > > Hey Larry, Ilija, > > I have on

RE: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> -Original Message- > From: Larry Garfield > Sent: Wednesday, May 29, 2024 10:03 PM > > On Wed, May 29, 2024, at 7:53 PM, Andreas Hennings wrote: > > Hello Larry, > > just a quick thought. > > Is there a reason why we cannot just make it "public private string > > $x" instead of "public

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, May 29, 2024 at 10:18 PM Larry Garfield wrote: > As promised, Ilija and I offer this revised version of asymmetric > visibility. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > Hey Larry, Ilija, I have one concern so far, and it's related to the inheritance section. If in a cl

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, May 29, 2024, at 7:51 PM, Tim Düsterhus wrote: > Hi > > On 5/29/24 21:15, Larry Garfield wrote: >> * We've brought back the abbreviated form, as public-read, something else >> set is the most common use case. > > The most common use case is that 'get' and 'set' are symmetric. OK, fair, I

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi On 5/29/24 21:53, Andreas Hennings wrote: Is there a reason why we cannot just make it "public private string $x" instead of "public private(set) string $x"? We would define that the second visibility specifier is for write. The current proposal with "public private(set)" is less ambiguous,

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Wed, May 29, 2024, at 7:53 PM, Andreas Hennings wrote: > Hello Larry, > just a quick thought. > Is there a reason why we cannot just make it "public private string > $x" instead of "public private(set) string $x"? > We would define that the second visibility specifier is for write. > > The curre

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hello Larry, just a quick thought. Is there a reason why we cannot just make it "public private string $x" instead of "public private(set) string $x"? We would define that the second visibility specifier is for write. The current proposal with "public private(set)" is less ambiguous, and it is imm

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

Hi On 5/29/24 21:15, Larry Garfield wrote: * We've brought back the abbreviated form, as public-read, something else set is the most common use case. The most common use case is that 'get' and 'set' are symmetric. Any divergence from that should stand out and I think that the hamming distan

[PHP-DEV] [RFC] Asymmetric Visibility, v2

As promised, Ilija and I offer this revised version of asymmetric visibility. https://wiki.php.net/rfc/asymmetric-visibility-v2 It's still essentially the same as last year's version, but with a few adjustments and changes: * readonly properties are now supported in a logical fashion. * We've

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 "private(se

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 ReflectionProperty::s

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 declara

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: > > ```php

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

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 rea

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 >> secti

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 intro

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 wonde

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 th

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 t

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 exi

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 intenti

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, bu

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 q

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 readonl

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 should

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 Pach

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 (ge

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 th

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, bot

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 previ

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, it

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 visibili

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 protected_set/

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). >> >> --Lar

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 se

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)`

  1   2   >