Asymmetric Visibility v2

Asymmetric visibility gives more fine-grained control over when a property can be read or written to. For example: you can make a property readable from everywhere, but only writable from within the private scope.

class Foo
{
    public private(set) string $bar = 'baz';
}
Click the bar to cast your vote!
36%
64%
1

For those saying "No," ask yourselves if it's the feature itself you're opposed to, or the level of knowledge you will need in order to use it properly. Then ask whether you'll need this language feature. If you don't need it, don't use it. If you don't want to learn it, don't. But I feel it's good for the language to regain traction in the development space if it's capable of the same patterns as others.

Aside from competition, I like this feature for the following:

  • Eliminate getter/setter methods that are nothing but cruft on top of direct read/write access of the property. Get back to writing functions that do things, not just carry the property in and out of the object.
  • Control object state more flexibly instead of micromanaging properties between parent/child inheritance
  • Reduce the boilerplate of constructors having to declare parameters instead of promoted properties, then pass the argument up to the parent's promoted property.

The syntax in the RFC adds complexity, yes. But we've all gotten used to other degrees of complexity as the language has grown and matured. Remember when visibility wasn't even a thing yet? Remember when constructing an object required a method matching the class's name? Growing pains hurt sometimes, but that doesn't mean they're not worthwhile.

Share:
thookerov avatar
thookerov
voted yes
1

I like the feature but don't like the syntax. something like this is better:

private writable $var;
private readable $var;

Share:
zackaj avatar
zackaj
voted no
1

Way to confuse new developers! Let's learn them to write private private(set) readonly string $foo; so they want to stop developing and consider starting careers in other fields...

As with a lot of new exceptions to the standard, where do you draw the border in introducing new stuff? Do you also create super custom Exception classes like BookWithTheSameTitleAlreadyExistsException?

What does introducing 'asymmetric visibility' really solve? Writing a bit of boilerplate? Should we then also make an rfc to replace try-catch in a function with something stupid as a fallback in case something throws Exception/Error/etc. or something?

Programming languages should focus on readability for developers. Computers can handle complexity without a sweat, but we as people have limited brain power. Personally, I like to keep my code simple. It should require as little brain capacity as possible to read through my code. That way, we can focus on the general flow and possible bugs.

Share:
mjverhage avatar
mjverhage
voted no
1

I don't have any arguments to add other than: It adds a lot of complexity and potential confusion for (IMO) negligible gain.

I would really like to see actual use cases (and less foobar) because I truely can't think of valid ones.. For mutable constructs I would just use methods to change the state and for immutable constructs readonly does the trick for me.

clone with would be nice, but this works reasonably fine for me:

final readonly class SomeClass
{
    public function __construct(
        public string $prop1,
        public bool $prop2,
    ) {}

    public function with(
        string $prop1 = null,
        bool $prop2 = null,
    ): self {
        return new self(
            $prop1 ?? $this->prop1,
            $prop2 ?? $this->prop2,
        );
    }
}

to be used with named arguments like

$someClass->with(
  prop1: 'changed',
);
Share:
bastian avatar
bastian
voted no
1

It is confusing for me, I think readonly is enough for most use cases, this will be complex and probably will not cover some edge cases, so new features will be placed on top? It should not be in the language.

Share:
williandamasceno avatar
williandamasceno
voted no
1

Let us rather remove the writeonce behavior from readonly and add a separate writeonce keyword.

The private(set) syntax is also ugly.

Share:
geoffreyvanwyk avatar
geoffreyvanwyk
voted no

Check out another RFCs

new MyClass()->method() without parentheses

Chain method on newly created objects without parentheses

54
95 yes
16 no
Property Hooks

A new way of interacting with properties

70
141 yes
90 no
The Pipe Operator

The "pipe operator" |> allows you to chain multiple function calls in a more convenient way.

93
272 yes
131 no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!