[RFC] Asymmetric visibility

Hi,
Am 05.08.22 um 19:08 schrieb Larry Garfield:

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.

Great to hear that there is a new and simple proposals.

One note: In the example about references, I assume the class Baz must
extend from Foo.

Good luck with this proposal
Thomas

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the
same.

I have two comments:

• For reflection purposes, having two separate methods feels like it will
  be cumbersome; you'd need to check both to determine if you'd need to make
  the reflection property accessible before changing the value. An
  isPublicSet() would alleviate that, or potentially a getSetFlags() method
  against which you could apply a bit mask. You'd need to add a constant for
  public set I both cases.

• The number of items that appear to the left of a property is growing,
  making understanding a declaration increasingly difficult, and your
  discussion of future scope indicates that this is likely to get worse. I'm
  wondering if this sort of behavior could be indicated via attributes
  instead? Something like #[PropertySetBehavior(PROPERTY_SET_PRIVATE)].
  Attributes have the benefit of being separate from the property
  declaration, arguably more readable (one per line), and composable. This
  might play into some of the future scope items as well.

Overall, though, love the design simplicity!

--
Larry Garfield
larry@garfieldtech.com

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi Larry,

pt., 5 sie 2022, 19:09 użytkownik Larry Garfield larry@garfieldtech.com
napisał:

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the
same.

Thanks for taking efforts on new RFC.

Why not C# style property accessors? It feels more natural for me while
Swift solution IMHO looks weird/odd composed with PHP class definition
syntax. The arguments in favor from the RFC look forcibly (couldn't find
better word).

Cheers,
Michał Marcin Brzuchalski

Le 5 août 2022 à 19:08, Larry Garfield larry@garfieldtech.com a écrit :

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.

--
Larry Garfield
larry@garfieldtech.com

Hi,

I like the RFC, and in particular allowing property visibility to remain orthogonal to property accessors.

There are few missing details in the RFC (which is otherwise good):

1. Are static properties supported?

2. What about properties that are overridden/redeclared in a subclass? Given that extending the visibility is generally allowed:

class A { 
	protected int $x;
}
class B extends A {
	public int $x; // ok
}

I expect that the following should be allowed as well:

class A { 
	public protected(set) int $x;
}
class B extends A {
	public int $x; // ok
}

On the other hand, I expect that the two following cases should not be allowed, because it would break encapsulation of class A:

class A { 
	public private(set) int $x;
}
class B extends A {
	public int $x; // error: cannot change a private property to public (or protected)
}

and:

class A { 
	public private(set) int $x;
}
class B extends A {
	public private(set) int $x; // error: cannot make a private property in A as private in B
}

—Claude

On Fri, Aug 5, 2022 at 8:09 PM Larry Garfield larry@garfieldtech.com
wrote:

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the
same.

--
Larry Garfield
larry@garfieldtech.com

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi Larry, Ilija,

Review the proposal and it looks great.

I have a few subjects to point and maybe discuss further if you think so:

1. The first subject is visible even from the first phrase of the RFC that
   uses both the terms "get and set operations" and "read and write
   operations".
   I'm wondering if you thought about using protected(write) or private(write).

2. The term "asymmetric visibility" is not that accurate and I believe
   "asymmetric access" or "asymmetric accessibility" would fit better.
   As noted in the relation with __set(), a public private(set) property that
   is attempted to be written from global context will not act like it's not
   visible but that it's not accessible for writing.

3. I assume the target is both static and non-static properties.
   This should be mentioned in the RFC.

Regards,
Alex

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.

For what it's worth, here's my initial thoughts after reading the RFC:

1. In "Permitted visibility, it explicitly states that the "set" scope
   MUST be more restrictive than the "get" scope. However, no reason for
   this is provided. Please make the argumentation to support this choice
   explicit.

2. In "Interaction with __set" and "Relationship with readonly" the RFC
   states it wants to be consistent with the readonly behaviour, but that
   is a different keyword. IMHO, these modifiers should work independently
   of each other and are now improperly closely binded. If one wants
   readonly behaviour, use the readonly keyword.

3. I only see a hat-tip to the property accessors RFC regarding the
   chosen syntax.
   I'd like to see a more extensive discussion and consideration of various
   possible syntaxes.
   Some potential alternatives:

• "visibility(get) visibility(set) type $prop" - which makes it explicit
  what each visibility applies to
• "visibility(set: visibility) type $prop" - where it is clear that the
  "main" visibility is the default and anything within the brackets a
  deviation. This syntax would also more easily allow for expanding, like
  "visibility(set: visibility, unset: visibility) type $prop"

I understand the desire for parallelism with Swift, but I don't think
that's a valid argument. The syntax should be right for PHP and if that
would happen to overlap/sync with a syntax used elsewhere: great, but
that's not an argument to only look at that syntax without a proper
discussion and due consideration for alternatives.

4. While I see no mention of "multi-property declarations", I presume
   the visibility would apply to all ? I think it would be good to mention
   this explicitly in the RFC as well.

   • By "multi-property declarations", I mean: `public string $type,
     $value = 'me', $somethingElse;

5. Are there tokenizer implications ? How will set (and possibly
   get) be tokenized ?

6. As this is something which can already be handled via magic methods,
   is there sufficient reason to make the language/engine more complicated
   to support this via a syntax ?

Overall, I mainly just see an idea in the RFC, but no justification for
the need for it, let alone for any of the choices made.

Smile,
Juliette

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Conceptually, I believe this would add useful capabilities to PHP that are impossible to implement without:

a.) Likely-sizable performance penalties, and
b.) Unfortunate edge-cases; e.g. property_exists(), get_object_vars(), etc.

Still, here are my concerns with the RFC as it currently exists:

1.) The syntax of "<keyword>(<keyword>)" feels inconsistent with the rest of the language.

PHP has function(args...) and (<type>), both of which can be viewed as "a function of 'args'." However, "private(set)" is basically a constraint, not a "function of 'set'."

PHP also has function(args...):<type> which is a constraint so I propose we consider the following syntax instead:

<visibility>:<operation>

Thus all of these:

public:get
public:set
private:get
private:set
protected:get
protected:set

2.)The idiom "public private:set" is hard to reason about when reading, at least for me.

It also feels inconsistent in that it requires one type of visibility to be constrained, but not the other.

Speaking of "explicit" from one of Larry's latest replies, I propose we consider requiring asymmetric visibility explicitly declared, in all cases. Requiring explicit declaration would:

a.) Make asymmetric visibility easier to reason about, and
b.) Ensure consistency when asymmetric visibility is used.

Specifically I would propose we make these INVALID:

public protected:set <type> $<var>;
public private:set <type> $<var>;
protected private:set <type> $<var>;

But all of these following VALID:

These as-is for backward compatibility and an obvious default behavior:

public [<type>] $<var>;
protected [<type>] $<var>;
private [<type>] $<var>;

And these where behavior is explicit:

public:get protected:set <type> $<var>;
public:get private:set <type> $<var>;
protected:get private:set <type> $<var>;

As well as these:

public:set protected:get <type> $<var>;
public:set private:get <type> $<var>;
protected:set private:get <type> $<var>;

And of course these:

public:get public:set <type> $<var>;
private:get private:set <type> $<var>;
protected:get protected:set <type> $<var>;

3.) I have concerns about the proposed methods isProtectedSet() and isPrivateSet().

These names feels like we are asking if some thing "Set" is "Protected" or "Private" where no such "thing" exists in this context.

In other words it reads as if you are asking "Is it a protected Set?" or "Is it a private Set?" Such naming also does not relate to the Property itself which is what the prefix verb "is" is acting on.

I would propose instead we consider the following are these instead would be asking the ability to "Set" the Property is "Protected" or "Private" where The Property is again what the prefix verb "is" is acting on:

isSetProtected()
isSetPrivate()
isGetProtected(), and
isGetPrivate()

#jmtcw

-Mike

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.

--
Larry Garfield
larry@garfieldtech.com

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi Larry,

I like most of this, but I have one disagreement.

Can you expand a bit more on the reasoning for restricting the ability to combine __set() here?

The RFC states that it’s to keep consistency with readonly, because __set on a readonly property that’s initialised throws an error - but isn’t that because of the nature of it being readonly, rather than because of the visibility rules? The error given is "Cannot modify readonly property” thrown from within the __set() method, not "Cannot access protected property” thrown from the outside calling context, when the __set() method is not implemented.

If I set a property to readonly I would expect it to not be settable after initialisation, regardless of visibility, whether it’s via direct access or via __set, etc. (i.e. what readonly does now)

But if I set a property to public private(set) for example, I would expect that the __set method on that class (or in the hierarchy if using protected(set)) would be called when setting it from an inaccessible context, just as it would be called when setting a regular protected property.

It seems very unintuitive to me, that the first example here would work, but that the second would not work:

class Foo {

protected readonly int $bar;

public function __set(string $name, mixed $value): void {
    $this->{$name} = $value;
}

}

$a = new Foo;
$a->bar = 1;

class Bar {

public protected(set) int $baz;

public function __set(string $name, mixed $value): void {
    $this->{$name} = $value;
}

}

$b = new Bar;
$b->baz = 1;

Cheers

Stephen

On Fri, Aug 5, 2022 at 7:09 PM Larry Garfield larry@garfieldtech.com
wrote:

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the
same.

--
Larry Garfield
larry@garfieldtech.com

--

To unsubscribe, visit: https://www.php.net/unsub.php

Just wanted to point out that I loved syntax proposals by Juliette and
Mike. Any of them would be better. Making a better syntax for PHP would be
better than consistency with Swift, IMO.

But I'm also inclined to agree with Marco Pivetta that this change is a lot
less exciting now that we have readonly. In extremely rare cases where I
need to modify an attribute more than once, I just fallback to private +
getter and the nice thing about it is that it creates a consistent mindset
that if a property is being accessed via a getter, then the reader should
be advised that the property may change depending on WHEN it's accessed.

--
Marco Deleu

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the
same.

Thank you Larry and Ilija for this RFC.

After reading it, I'm wondering about inheritance rules. What would be the
rules when redeclaring an existing asymmetric property in a child class?
The RFC should mention them I believe.

But I'm also wondering about the use case where asymmetry would be useful
in practice now that we have readonly?
I voted against readonly at the time because it didn't address cloning, and
also because it deprives end-users vs code authors IMHO (alike "final"). I
would have very much prefered asymmetric visibility back then. But now that
we are here, what are the use cases? If it's cloning only, then I would
very much prefer finding a way to fix it rather than providing two subtly
different ways to achieve the same thing.

Eg can't we allow __clone methods to bypass the readonly restrictions? The
engine already handles "guards" when using magic property accessors. Can't
we use something similar for clone?

And if yes, what would remain of the motivations for the asymmetric RFC?

Cheers,
Nicolas

Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.

https://wiki.php.net/rfc/asymmetric-visibility

Details are in the RFC, but it's largely a copy of Swift's support for the same.

Hi folks. Ilija and I have been discussing and experimenting extensively based on the feedback to the first draft. Here's our thoughts so far, some additional data, and a request for feedback. (These changes haven't been made to the RFC just yet, as there's outstanding questions for which we want feedback below.)

1. Rather than readonly being forbidden on asymmetric properties, it's better to redefine it as "write once, and if no set visibility is defined, make it private." That would still allow for public protected(set) readonly string $blah (to work around existing limitations in readonly), but also more or less preserve the current syntax in a logical way.

2. Given that... we're not sure that it makes sense to have any visibility scope other than get/set. once becomes unnecessary with that understanding of readonly, and we cannot think of any other examples that are not a stretch. So that axis of extensibility is of minimal importance.

3. Since there has been some confusion, our goal is to implement property accessors in the future as a follow-on to this RFC. However, conceptually property "hooks" and asymmetric visibility are separate features. They also both have ample bikeshed potential. That's why we're proposing them as two separate RFCs. (Technically property hooks could also be done first, but this one is smaller.) That said, it's become obvious that we cannot avoid discussing property hooks at the same time since the syntax does overlap. So in the discussion below I will include property hooks, but deliberately gloss over parts that are not relevant right now. Please humor me and do the same. :-)

4. In concept, there's two main syntactic models for property hooks/accessors: Javascript/Python style (annotated methods) and Swift/C# style (method-esque code blocks on properties). We were trying to keep our options open and avoid a syntax that locks us into one or the other. However, we've concluded that the annotated methods style just wouldn't work at all in a language with explicit types and visibility controls. We've therefore made the executive decision that only the Swift/C# style is an option.

5. That leaves the basic question of "where to put the visibility," as Swift and C# put them in different places. (There are other differences not relevant for now.)

Swift:

class User {
   public private(set) var first: String
   public private(set) var last: String
  
   public private(set) fullName: String {
       get { ... }
       set { ... }
   }
}

C#:

class User {
   public string first { get; private set; }
   public string last { get; private set; }
  
   public string fullName {
       get { ... }
       private set { ... }
   }
}

The relevant difference is that in Swift, all visibility is on the left of the property while in C# it is split between the left and right.

The main argument for Swift-style: Keep everything in one place, and if there's no property hooks we don't even have to think about it.

The main argument for C#-style: It avoids repeating a keyword (eg, set) if using both features.

It may be possible to omit the get in the C# example above if it's just the default. Ilija is still working to figure that out.

References make everything worse

One other caveat to consider is (naturally) references. A get hook cannot return by reference, as that would allow setting the value via its reference and bypassing a set hook.

A side effect of that restriction is that arrays cannot be modified in place on properties with a get hook. That is, assuming the $bar property is an array that leverages the extra hooks above (by whatever syntax), the following is not possible:

$f = new Foo();

$f->bar[] = 'beep';

That would require returning $bar by reference so that the [] operation could apply to it directly. However, that then bypasses any restrictions imposed by a set hook (such as the values had to be integers). The following, however, would be legal:

$f = new Foo();

$b = $f->bar;

$b[] = 'beep';

$f->bar = $b;

That problem wouldn't happen if all we're changing is visibility, however. That means in the C# style, we would need to differentiate whether the block on the right is intended to disable references or not. Ilija has proposed raw to indicate that. That would mean:

class Test
{
   public $a { private set; }
   public $b { private raw; }

   public function inScope()
   {
       echo $this->a; // echo $this->getA();
       $this->a = 'a'; // $this->setA('a');
      
       echo $this->b; // echo $this->b;
       $this->b = 'b'; // $this->b = 'b';
   }
}

$test = new Test();

echo $test->a; // echo $test->getA();
$test->a = 'a'; // Error, set operation not accessible

echo $test->b; // echo $test->getB();
$test->b = 'b'; // Error, set operation not accessible

The take-away for the asymmetric visibility only case is that we would need to use raw instead of set, in order to avoid confusion later with accessor hooks and whether or not to disable references.

The Swift-style syntax, as it does not require any hook-like syntax to just control visibility, does not have this problem. There is no ambiguity to resolve, so no need for a raw keyword.

Common use cases

While there are a myriad of possible ways to use both asymmetric visibility and property accessor hooks, we anticipate three usage patterns to predominate:

1. Public read, private/protected write, but that's it.
2. Public read, public write, but some extra validation on set.
3. Public lazily-derived value, no write.

In particular, it seems to us (though we have no precise data to back it up) that it is unlikely that both asymmetric visibility and property hooks would be used at the same time, in the typical cases. That should inform the discussion about syntax.

Comparison

For the moment I'm just going to use Swift-style as-is. There's a discussion later to be had about minor variations on it, as suggested by a few people in the previous thread. Stand by.

Length comparison:

// Current code, for comparison
public readonly string $first;

// Swift-ish
public private(set) string $first;

// C#-ish, note "raw" because there's no hook
public string $first { get; private raw; }

Both options suggest possible shorthands:

// Current code, for comparison
public readonly string $first;

// Swift-ish
private(set) string $first;

// C#-ish, assuming it can be done
public string $first { private raw; }

If combining with readonly, we get:

// Current code, for comparison
public readonly string $first;

// Swift-ish
public protected(set) readonly string $first;
protected(set) readonly string $first;

// C#-ish
public readonly string $first { get; private set; }
public readonly string $first { private raw; }

If we mix in for-reals accessor hooks, we get:

// Swift-ish
public private(set) string $first {
   get { ... }
   set { ... }
}

// C#-ish, note now we're using "set".
public string $first {
   get { ... }
   private set { ... }
}

If other hooks are added (Swift has beforeSet and didSet, and we intend to include those as well for PHP), they don't really make sense to have visibility modifiers on them. It's arguable if isset or unset (to mirror the existing magic methods) would want those. Does it make sense to have "public read, public set, but private unset"? Or is unset just controlled by set? Unclear.

Another complication is that, for forward compatibility, we would need a way to disable references on no-hook properties so that hooks could be added later without a change in reference behavior. Given the postfix syntax for hooks, we believe the most natural way to do that would be:

// Swift-ish
public string $foo {}

// C#-ish
public string $foo {}
// which is shorthand for:
public string $foo { public raw; }

Again, the C# model implies a bit more complexity and nuance.

Questions

Question 1: Which general model (Swift or C#) is preferable, and why?

(At the moment, Ilija and I disagree on which one is preferable. Hence, poll.)

If Swift

If we go with Swift-style, several people suggested alternative syntax options. This is mostly a bikeshed question, so I will just list them:

public private(set) string $first;
public private:set string $first;
public:private string $first;
public private string $first;
public(set: private) string $first;

Some of which have natural shorthands:

private(set) string $first;
private:set string $first;
:private string $first;
N/A
N/A

Question 2: IF we go with Swift-style, which of the above syntaxes would you prefer, and why?

Please answer both questions only via this poll so can collect actual data.

https://docs.google.com/forms/d/e/1FAIpQLSefq15VvGNIXSnQaMTl3RW451w0E8oesny8c4PLqmKl8HhQ-Q/viewform

Thank you all for your time and input.

--Larry Garfield and Ilija Tovilo