Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119242
MIME-Version: 1.0
References: <ec2c86fc-53df-4ef2-ae9b-5e5dc76fbb3c@app.fastmail.com>
In-Reply-To: <ec2c86fc-53df-4ef2-ae9b-5e5dc76fbb3c@app.fastmail.com>
Date: Mon, 9 Jan 2023 17:00:59 +0100
Message-ID: <CAOWwgpnwpNWVMas98oPk_qkRJYZFK6CGuvCJa6v1sbKVxcOKYg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003f792f05f1d6e0c2"
Subject: Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000003f792f05f1d6e0c2
Content-Type: text/plain; charset="UTF-8"

> I am hereby opening the vote on the Asymmetric Visibility RFC:
>
> https://wiki.php.net/rfc/asymmetric-visibility
>
> Voting will be open for 2 weeks.
>
> While we would certainly prefer if everyone voted in favor, for those who
> vote against the authors kindly request that you indicate why, using the
> second poll question or comment section afterward.  Thank you.
>

Hi Larry, Ilija,

Thanks for opening the vote. I played a bit with the code and I didn't spot
any unexpected behavior, nice work.

I'm undecided for now, on two points:
1. the syntax: looking at https://wiki.php.net/rfc/property-hooks, I wonder
if using public string $foo {private set;} wouldn't be more appropriate.
Otherwise, it might be strange to have public private(set) string $foo {set
($value) { /* the setter */};} if hooks are the way forward. Sure we could
compact that but that would introduce two very different syntax whether a
setter is defined or not. WDYT?
2. the feature itself: I feel like this new syntax doesn't open new
capabilities over using methods, so this might "just" add complexity in the
end, adding alternative ways to do something already doable (I'm making the
argument for hooks also BTW). Would you be able to clarify why we need
this? (The only new capability that feels appealing to me is the "init"
modifier, but this is not what this RFC is about.)

About my point 2., did you consider a syntax to map a getter+setter to
properties? That might fill the need for asym visibility + hooks in one go?
I'm seeing quite often libraries that do this sort of mapping based on
conventions. This would bake the practice into the language:

public string $foo {get: getFoo, set: setFoo} or something like that, with
method visibility being added on top of the property visibility.

Sorry to chime in that late, I'm really undecided and discussing those
topics would help.

Thanks,
Nicolas

--0000000000003f792f05f1d6e0c2--