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
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
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
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
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
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
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
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
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
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
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
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
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-
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
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
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.
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:
>
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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:
*
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
> 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
"
> 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
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)
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
> 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
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
> 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
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
> 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
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
> -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
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
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
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,
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
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
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
56 matches
Mail list logo
