Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
On Fri, Jan 6, 2023, at 5:37 PM, Larry Garfield wrote: > 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 folks. Two brief things I want to mention as they have come up in other discussion: First, I mentioned this in my reply to Nicolas, but it could easily have gotten buried: Based on the fore-work that Ilija has done on property hooks in the last 3-ish weeks, we feel confident in saying: 1. Hooks will most likely not be practical on array properties at all. 2. That means if asymmetric visibility were to use hook-style syntax, asymmetric visibility would not be supported on arrays. That is the final nail in the coffin for that approach, in our view. We can have asymmetric visibility on array properties, or we can use C#-style hook-based syntax for it. We cannot (reasonably) have both. Given that, we feel very firmly that the current proposal (Swift style) is the only feasible syntax to use for asymmetric visibility. Second, Theodore Brown noted on the RFC in the comments section (thank you): "Proposal feels unfinished since it can't be used in conjunction with readonly properties/classes. In my opinion the issues with this need to be resolved first, to avoid the language moving towards a messy hodgepodge of features that don't work well together." We are confident that readonly and a-viz can be combined in the future. It's not a "messy hodgepodge". However, there is a design question around same-visibility and readonly that was discussed in a previous thread (named "Asymmetric visibility, with readonly"), and the consensus there was to hold off on that question until later. So, we're following the consensus. In particular, we're keeping future options open in order to ensure that we don't end up with a "messy hodgepodge." Without a clear consensus on exactly how that should behave, holding off on it and keeping our future options open is the smarter, more responsible approach. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
Le mar. 10 janv. 2023 à 00:00, Larry Garfield a
écrit :
> On Mon, Jan 9, 2023, at 10:00 AM, Nicolas Grekas wrote:
> >> 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?
>
> As discussed, putting the visibility on the right has a number of problems.
>
> 1. If we assume that hooks in something similar to the current unreleased
> RFC happen (which I hope they do), then putting the visibility in the hook
> area creates additional problems.
>
> For one, hooks will require disabling getting a reference to a property.
> That is not negotiable, as getting a reference to a property would let you
> bypass the hooks. Aviz doesn't require that, though. If the only thing
> you're doing is private-set, then using the hooks syntax for aviz means
> either introducing yet another access marker, like "private raw" to
> indicate that you don't want to disable references (I don't want to have to
> explain that to people), or just sucking it up and saying that aviz
> disables references.
>
> But disabling references also makes `$obj->arrayProp[] = 4` break
> entirely. So that would make arrays completely incompatible with
> asymmetric visibility, when there's no actual reason that has to be the
> case.
>
> So in short, we end up with three options:
>
> A) The current proposed syntax.
> B) Having both "{ private set }" and "{private raw}", and having to
> explain WTH that even means.
> C) Arrays are incompatible with asymmetric visibility entirely, period.
>
> Of those, A is, I would argue, the clearly better option.
>
> 2. Some nerdy engine details, courtesy of Ilija. Basically, given the way
> we're looking at doing hooks, mixing the hook and a-viz syntax would make
> it *more* complicated, not less.
>
> We're hoping to completely avoid generated accessors ({ get; set; } with
> no additional behavior) completely. Essentially, all they do is disable
> indirect modification (i.e. modifying arrays with []) and references
> (assigning a reference or extracting a reference). The reason they have to
> do that is that both of those things allow mutating the value of the
> property in a way where we cannot call the accessors, either because the
> engine isn't aware of it or because there's no simple way to "feed" the
> modified value into the setter. There are two primary reasons generated
> modifiers existed in the previous draft: 1. To avoid a BC break when adding
> a hook in the future and 2. to allow sub-classes to override the property
> while staying compatible with the parent.
>
> As described here (
> https://gist.github.com/iluuu1994/4ca8cc52186f6039f4b90a0e27e59180#use-case-5-arrays-properties)
> we've come to the conclusion that this issue of incompatibility is almost
> exclusively restricted to array properties. However, there are other
> reasons why publicly exposing an array property with write access isn't a
> good idea, as outlined in the gist. In other words, this compatibility
> layer provided by { get; set; } was provided for something that shouldn't
> be a publicly writable property in the first place. We're now hoping to
> completely avoid the { get; set; } syntax which also makes public
> private(set) a better fit, instead of offering a fake { get; private set; }
> syntax that is either limiting (i.e. not working properly for arrays) or
> semantically inconsistent (not preventing indirect modification and
> references).
>
> 3. More stylistically, it means visibility may end up split in two
> different locations. That's harder for people to read.
>
> Especially if we add hooks later, it means they could be several lines
> apart! Consider:
>
> public string $foo {
> beforeSet {
> return strtolower($value);
> }
> afterSet {
> $this->modified['foo'] = true;
> }
> get => $this->_foo;
> protected set => $this->_foo = $value;
> }
>
> This is a worst-case example, but worth considering as it would be valid,
> legal syntax and almost certainly appear in the wild. The "set visibility"
> is 8 lines away from the "get visibility."
Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
Hi, I was looking at the current vote of this RFC and I stumbled upon Theodore's remark that the RFC feels unfinished as it can't be used in conjunction with readonly properties/classes. The RFC disallows (for the time being) the mixing of readonly with explicit asymmetric visibility. And I was happy about it. Thus I didn't feel the need to comment about it so far. The main motivation given in the readonly RFC was value objects. And as far as I understand, one of the main reasons was to reduce boilerplate code (esp. public getters). readonly works fine for value objects. But looking at entities, there is no solution so far. Thus I still (might) need to provide public getters. And because of the limitations of readonly, there was/is a need for asymmetric visibility. I doubt, there would be any need for readonly if we would have had asymmetric visibility first. And (using asymmetric visibility) I assume, developers should be able to ensure that a property is 1. only initialized once, 2. inside the limited scope of a class, and 3. not overwritten during the lifetime of the object. I'd be interested in a use case where you would really like to ensure this on the engine level. To go one step further, I would even ask the heretical question if we should discourage/deprecate readonly once we have asymmetric visibility. ;-) Regards Thomas Am 07.01.23 um 00:37 schrieb Larry Garfield: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
On Mon, Jan 9, 2023, at 10:00 AM, Nicolas Grekas wrote:
>> 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?
As discussed, putting the visibility on the right has a number of problems.
1. If we assume that hooks in something similar to the current unreleased RFC
happen (which I hope they do), then putting the visibility in the hook area
creates additional problems.
For one, hooks will require disabling getting a reference to a property. That
is not negotiable, as getting a reference to a property would let you bypass
the hooks. Aviz doesn't require that, though. If the only thing you're doing
is private-set, then using the hooks syntax for aviz means either introducing
yet another access marker, like "private raw" to indicate that you don't want
to disable references (I don't want to have to explain that to people), or just
sucking it up and saying that aviz disables references.
But disabling references also makes `$obj->arrayProp[] = 4` break entirely. So
that would make arrays completely incompatible with asymmetric visibility, when
there's no actual reason that has to be the case.
So in short, we end up with three options:
A) The current proposed syntax.
B) Having both "{ private set }" and "{private raw}", and having to explain WTH
that even means.
C) Arrays are incompatible with asymmetric visibility entirely, period.
Of those, A is, I would argue, the clearly better option.
2. Some nerdy engine details, courtesy of Ilija. Basically, given the way
we're looking at doing hooks, mixing the hook and a-viz syntax would make it
*more* complicated, not less.
We're hoping to completely avoid generated accessors ({ get; set; } with no
additional behavior) completely. Essentially, all they do is disable indirect
modification (i.e. modifying arrays with []) and references (assigning a
reference or extracting a reference). The reason they have to do that is that
both of those things allow mutating the value of the property in a way where we
cannot call the accessors, either because the engine isn't aware of it or
because there's no simple way to "feed" the modified value into the setter.
There are two primary reasons generated modifiers existed in the previous
draft: 1. To avoid a BC break when adding a hook in the future and 2. to allow
sub-classes to override the property while staying compatible with the parent.
As described here
(https://gist.github.com/iluuu1994/4ca8cc52186f6039f4b90a0e27e59180#use-case-5-arrays-properties)
we've come to the conclusion that this issue of incompatibility is almost
exclusively restricted to array properties. However, there are other reasons
why publicly exposing an array property with write access isn't a good idea, as
outlined in the gist. In other words, this compatibility layer provided by {
get; set; } was provided for something that shouldn't be a publicly writable
property in the first place. We're now hoping to completely avoid the { get;
set; } syntax which also makes public private(set) a better fit, instead of
offering a fake { get; private set; } syntax that is either limiting (i.e. not
working properly for arrays) or semantically inconsistent (not preventing
indirect modification and references).
3. More stylistically, it means visibility may end up split in two different
locations. That's harder for people to read.
Especially if we add hooks later, it means they could be several lines apart!
Consider:
public string $foo {
beforeSet {
return strtolower($value);
}
afterSet {
$this->modified['foo'] = true;
}
get => $this->_foo;
protected set => $this->_foo = $value;
}
This is a worst-case example, but worth considering as it would be valid, legal
syntax and almost certainly appear in the wild. The "set visibility" is 8
lines away from the "get visibility." Too, the hooks are more confusing
because only one of them supports an extra keyword; the other three have none.
Even in a more reasonable ordering:
public string $foo {
get => $this->_foo;
protected set =>
Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
> 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
[PHP-DEV] [RFC][Vote] Asymmetric Visibility
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. -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
