Re: [RFC] Asymmetric Visibility, v2

From: Date: Fri, 26 Jul 2024 11:36:55 +0000
Subject: Re: [RFC] Asymmetric Visibility, v2
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
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 was split, but leaned toward the prefix-style syntax.  So we went with that.  I don't think we'll ever get everyone to want the same syntax, but we're using the one that was both somewhat more popular, and (as discussed in the RFC) arguably superior.

As the "comments in yield from" thread has shown, *any* even slight change to PHP's syntax will require work from static analysis tools.  That's the nature of the problem space, regardless of the syntax specifics.

--Larry Garfield



Just to play devil’s advocate, it was also before we had property hooks who advertised itself as a way to “wrap and guard access to object properties” but we are simply ignoring their existence here.

Just to compare them, because my initial gut feel was to say "yes please just put this together with hooks"..


As far as I understand these would be the two options?


     class C {
         public protected(set) $answer { get => 42; set => { $this->answer = $value * 2; }
         public private(set) $publicReadOnly;
     }




     class C {
         public $answer { get => 42; protected set => { $this->answer = $value * 2; }
         public $publicReadOnly { private set; }
     }


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 what visibility applies.

Best,
Jordi

-- 
Jordi Boggiano
@seldaek -https://seld.be

Thread (57 messages)

« previous php.internals (#124607) next »