Re: [PHP-DEV] [RFC] Asymmetric visibility

[Larry Garfield]

On Wed, Aug 31, 2022, at 4:26 PM, Tim Düsterhus wrote:
> Hi
>
> On 8/31/22 22:43, Larry Garfield wrote:
>> ## References make everything worse
>> 
>> […]
>> 
>> 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:
>> 
>> ```php
>> 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.
>> 
>
> I've read through that explanation three times, but don't understand why 
> the C#-style syntax would require to differentiate between `set` and 
> `raw`. Isn't the difference between "visibility only" and "accessor" not 
> clear [1] by having either '{' or ';' after the 'set'?
>
> [1] Read: Clear to the engine, not talking about the human reader here.

Yeah, it's complicated, and Ilija had to explain it to me several times. :-)

The tricky part is that there's *three* different toggles involved here.

1. Asymmetric visibility.
2. Accessor hooks.
3. Disabling references on properties.

Invoking 2 necessarily implies also doing 3, for reasons given above.  However, 
we also want people to be able to enable 3 on its own, so that IF they enable 
accessor hooks later, it is transparent and doesn't imply breaking references 
unexpectedly.  (Viz, you could have a value object full of `public string $foo 
{}` type properties, which disables references, and then slip in a get/set hook 
later and no one notices.)

So we need a way to indicate "I'm using a-viz, and disabling references" as 
well as "I'm using a-viz, and not disabling references."

With the Swift style syntax, that's super straightforward.

public string $foo; // No a-viz, references work.
public string $foo {} // No a-viz, references disabled.
public private(set) string $foo; // a-viz, references work.
public private(set) string $foo {} // a-viz, references disabled.

And the {} makes a convenient marker because you'd be adding it in the future 
anyway if you add hooks, which would force disabling of references.  So it's a 
natural flow from one option to the next.

With the C# style, a-viz means you're *always* putting braces on the right, so 
we cannot do that.  Instead, you need

public string $foo; // No a-viz, references work.
public string $foo {} // No a-viz, references disabled.
public string $foo { private raw; } // a-viz, references work.
public string $foo { private set; } // a-viz, references disabled.

So then the toggle for disabling references is "there's a set or get keyword 
inside the braces", but we then need a different keyword for "I'm *just* doing 
a-viz, and I don't want to disable references."  Hence, "raw".

(I'm assuming in the above that Ilija is able to make omitting the "get; set;" 
if there's no body for them. He's reasonably sure we can but hasn't confirmed 
it.)

Is that clearer?

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Claude Pache]

> Le 31 août 2022 à 23:27, Tim Düsterhus  a écrit :
> I've read through that explanation three times, but don't understand why the 
> C#-style syntax would require to differentiate between `set` and `raw`. Isn't 
> the difference between "visibility only" and "accessor" not clear [1] by 
> having either '{' or ';' after the 'set'?
> 
> [1] Read: Clear to the engine, not talking about the human reader here.

Even if they manage to make the difference clear for the engine without 
resorting to “raw”, I think that it is important to have a syntactical marker 
for the sake of humans. Otherwise, someone would want to incrementally improve 
their class property, and at some unkwown point in time,  it becomes 
unexpectedly unusable for references and array mutations. 

—Claude 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Tim Düsterhus]

Hi

On 8/31/22 22:43, Larry Garfield wrote:

## References make everything worse

[…]

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:

```php
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.



I've read through that explanation three times, but don't understand why 
the C#-style syntax would require to differentiate between `set` and 
`raw`. Isn't the difference between "visibility only" and "accessor" not 
clear [1] by having either '{' or ';' after the 'set'?


[1] Read: Clear to the engine, not talking about the human reader here.

Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] No longer allow block mode for declare(encoding)

[Hans Henrik Bergan]

>it might be hard to properly implement support

No effort should be wasted supporting this.
+1

On Wed, Aug 31, 2022, 21:21 Sara Golemon  wrote:

> On Wed, Aug 31, 2022 at 10:43 AM Christoph M. Becker 
> wrote:
>
> > recently, there was a bug report regarding declare(encoding)[1].  I've
> > checked that, and found that the current implementation of
> > declare(encoding) doesn't make sense regarding "block mode", since this
> > is completely ignored; instead, each (allowed) declare(encoding) works
> > from where it is written till the next declare(encoding) (well, probably
> > more or less).
> >
> > Since I consider switching the character encoding in the middle of a
> > file not reasonable (and it might be hard to properly implement support
> > for that), I suggest to disallow block mode for declare(encoding) as of
> > PHP 8.3.  A respective PR is available[2].
> >
> >
> I think I can imagine scenarios where switching encodings within a file
> would work?  Especially for ASCII transparent encodings...  That said,
> if you're currently depending on multiple encodings in a single file then
> you probably deserve whatever you get.
>
> +1
>
> -Sara
>

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Larry Garfield]

On Fri, Aug 5, 2022, at 12:08 PM, Larry Garfield 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.

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:

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

C#:

```csharp
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:

```php
$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:

```php
$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:

```php
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;
   

Re: [PHP-DEV] No longer allow block mode for declare(encoding)

[Sara Golemon]

On Wed, Aug 31, 2022 at 10:43 AM Christoph M. Becker 
wrote:

> recently, there was a bug report regarding declare(encoding)[1].  I've
> checked that, and found that the current implementation of
> declare(encoding) doesn't make sense regarding "block mode", since this
> is completely ignored; instead, each (allowed) declare(encoding) works
> from where it is written till the next declare(encoding) (well, probably
> more or less).
>
> Since I consider switching the character encoding in the middle of a
> file not reasonable (and it might be hard to properly implement support
> for that), I suggest to disallow block mode for declare(encoding) as of
> PHP 8.3.  A respective PR is available[2].
>
>
I think I can imagine scenarios where switching encodings within a file
would work?  Especially for ASCII transparent encodings...  That said,
if you're currently depending on multiple encodings in a single file then
you probably deserve whatever you get.

+1

-Sara

[PHP-DEV] No longer allow block mode for declare(encoding)

[Christoph M. Becker]

Hi all,

recently, there was a bug report regarding declare(encoding)[1].  I've
checked that, and found that the current implementation of
declare(encoding) doesn't make sense regarding "block mode", since this
is completely ignored; instead, each (allowed) declare(encoding) works
from where it is written till the next declare(encoding) (well, probably
more or less).

Since I consider switching the character encoding in the middle of a
file not reasonable (and it might be hard to properly implement support
for that), I suggest to disallow block mode for declare(encoding) as of
PHP 8.3.  A respective PR is available[2].

Thoughts?

[1] 
[2] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php