thettler's avatar

Tobi

thettler

Member since

60

Total Reputation

1

Total Arguments

4

Total Votes for Arguments

Arguments and votes

4

I like the functionality this RFC provides and think this should come to PHP. But i don't like introducing a new keyword and syntax for this because it also increases the cognitive load. I would like the Property Hook approach that is discussed in the RFC more or using Attributes like the #[\SensitiveParameter]:

class Foo
{
	#[PrivateSet]
	public string $bar = 'baz';
}

or

class Foo
{
	#[Set(Private)]
	public string $bar = 'baz';
}

or some other Attribute. We should try to use existing syntax first.

Share:
Read the RFC: Asymmetric Visibility v2 thettler avatar
thettler
voted no
12

This really makes the language complex.
The part with the interactions with the readonly keyword is really hard to make sense of.

I understand the subtle differences, don't get me wrong, it's just that I cannot understand them by just looking at the property definitions quickly. Imagine having to quickly make sense of a class with a dozen of properties like that. It's just nightmarish. I wouldn't accept a merge request that messy in my codebase.

I feel like if you need that much fine-grain control this is when having explicit getters/setters make sense.

Add property hooks on top of that and you have an explosion of complexity where you don't want: your domain logic is complex enough on it's own, you don't want to have properties become a maze.

Share:
Read the RFC: Asymmetric Visibility v2 nreynis avatar
nreynis
voted no
9

It certainly is a fancy feature, but it takes too much a toll on the cognitive load.

Right now visibility is straight-forward. In a glance I can map in my head the possible operations on a property when I see its visibility. Adding this to the language will mean there will be moments that I'll have to stop and work out exactly what it means I can do with a property.

Also, property hooks already solve these use cases: defining a virtual property hook with only a getter will prevent you from setting the property, and vice versa.

Share:
Read the RFC: Asymmetric Visibility v2 yogarine avatar
yogarine
voted no
36

This is good to have.

Properties are useful for exchanging (reading and writing) single values. Properties are good for data binding, etc.

With this RFC we can implement:

  • Validation
  • Trigger events
  • Call methods if there is more to do

Update: About the $field I am not sure. Having a separate backing field can have some advantages.

Share:
Read the RFC: Property Hooks maz avatar
maz
voted yes
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!