Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123571 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 1E3451A009C for ; Mon, 10 Jun 2024 20:17:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1718050739; bh=lkFMCXwWgptHjTHyENeGLu7FXTgyciVtEOJ+C2BUnLE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XT4OHtkM9PYVCcWFAJrMdwzyRkS1kHhSh6/QgxLSf8g+NZY1W3yTMUBLxuiLad/RG HZABpLjTZ8/2ifYCY0vEdqaGFTm8yyJaefF5KlEX8tcqG0XGBtFGiTdVqDJ3G9jeXv 1gZ+FDYIMJvOx36IH1PA/dK5JBqglfWOyXSZCOq85mitzdktnFxxst5G41mpQyJJHX Dd9FC701ScLU61ukejW2VUk9HWzrlFQvGEAFXtKjoIl5ZSa8Uuwl2ylzeONViItYkF HP+yBnTA49Fwiuzf344poCT/Dv2mboVuBnhnSJ18PWsiuqmhBvuL67/rShBW6JbvPw vQQoTF8WXo89A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5FDFB180057 for ; Mon, 10 Jun 2024 20:18:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 10 Jun 2024 20:18:57 +0000 (UTC) Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-80c71bbc6f3so64487241.1 for ; Mon, 10 Jun 2024 13:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718050669; x=1718655469; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gqilaer/ago1DcHdIXwrYtd4GzxbvUzzZ0Aiz0/eZbw=; b=RPmI1IhuzNvYqHz89/uaPRsIka5qsudANRxDOlqUtozwOb2GDphNhzggMu8KKthZEx CXqYMW6Ca36g+4ZNQ8Bpz0OZ25Wy02YGhLB4oUD+j07TRCYROZCpdLT7EpzUDeeXYai0 RX0EIarelKTczvPJc/wKSgbIGwxJinjjDzbFYlCfYgpmDb4TZ2fKjpBq18aUNPDiu3KL VsO6DeJqeRoZZrZN9ub8zPvUNTxw8G9+fn13W8j0Db8pPMriLO5QqymQ7iJBgjOVAPae QHYww+6kBFfOIBoyHY6emAs+DnefBFcWj464VZ69yCwFIcHu98JLsyiV9wdLtG+FS9Wj 7vPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718050669; x=1718655469; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gqilaer/ago1DcHdIXwrYtd4GzxbvUzzZ0Aiz0/eZbw=; b=WPCd/YObiIpG2T4VxTmRKvuJoT3mnz6pwHp/PVypxZAyHdlt1NvC1Claujl8dfaxvx +bHlHUHUkasT9WDzovPgvlcuJ2UWYn8HGCrl7fVZmlGT42biW8JCkTHxm/poqh0dcGyW cK9GPz5c5f0CpqSkHcITav0FWx4VhdNCNUJ0yFDK1lON6yS/8UQOTlL7XHXezF0Q1wTq xtrGMANSfWS7t6nE4d2UYxbHvvtLDAQ+LHexQ8sJuR5iwZJ1kNUqj2mdkeAkcE3uiOMG ajoQ69t1O+nkrVFJdRpFJlUcg7Zg/6X2FiQlTAs84z09SiQI+lWwHvtQgOYeoAdK9KTe LWEw== X-Forwarded-Encrypted: i=1; AJvYcCUbwFOSeFcJVPCkdLWJePv2QRtbS6hwZ1P1crytL4Iah/HuRB08hXvW01uRSoLj2IGj1pLpXrxVCsAFQmg9MrGWTdXjSPvoow== X-Gm-Message-State: AOJu0YwDdDUjnqvJqQNHX9SxEZWQEFzUqLPjRH0DL5v5mAPKsZM+9jy5 RKCxOvaJxMXzYtEsl7nHzyVMUMJg6SGdllhSAdmD/V5UA/TvN3e4dnrJgxwz9vI+V8Tidp2cl8E DzmcSC8fYYc823gE4aWfa2lAF+RA= X-Google-Smtp-Source: AGHT+IHS73IBGZ5ZLP0ZOVMW6x9Nl44RBNYh2w5XA9OvbMVYNhLICSHusJryDZsZOm3MiQSt83n6o5+h/SY8MviFtsY= X-Received: by 2002:ac5:c0c2:0:b0:4e4:e90f:6749 with SMTP id 71dfb90a1353d-4eb562a4b74mr9268494e0c.10.1718050669314; Mon, 10 Jun 2024 13:17:49 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com> In-Reply-To: Date: Mon, 10 Jun 2024 14:17:38 -0600 Message-ID: Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2 To: Rodrigo Vieira Cc: Larry Garfield , Tiffany , php internals Content-Type: multipart/alternative; boundary="000000000000d9cdb8061a8ed7bb" From: lnearwaju@gmail.com (Lanre) --000000000000d9cdb8061a8ed7bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You guys are killing PHP. There is a lot of work to be done on the engine to modernize it and make it more robust and sturdy. Shit like this just adds more complexity to PHP in the name of convenience. I think this is my cue to explore other languages for handling requests On Mon, Jun 10, 2024 at 1:18=E2=80=AFPM Rodrigo Vieira wrote: > I didn't like the `Prefix-style` syntax. I prefer the > `Hook-embedded-style` syntax. First let's look at the counterpoints of th= e > `Prefix-style` syntax: > > ## 1) "`Prefix-style` is more visually scannable" > > The set visibility is 10 lines away from the get visibility! > > Solution: > ```php > class HookEmbeddedStyle > { > public string $phone { > private set { > $this->phone =3D implode('', array_filter(fn($c) =3D> > is_numeric($c), explode($value))) > } > get { > if (!$this->phone) { > return ''; > } > if ($this->phone[0] =3D=3D=3D 1) { > return 'US ' . $this->phone; > } > return 'Intl +' . $this->phone; > } > } > } > ``` > The set visibility is not 10 lines away from the get visibility if you pu= t > it at the top. For me this is about code convention, not about syntactic > structure: > only put the hook with explicit visibility at the top, when some of the > hooks do not have explicit visibility! > > ## 2) "`Prefix-style` is shorter" > ```php > public private(set) string $name; > > public string $name { private set; } > ``` > > Irrelevant to consider 1-2 characters. > If you break the lines needed for the hook block, the line (the horizonta= l > size) is smaller when using `Hook-embedded-style` and in my opinion it is > more readable because there is less information per line: > ```php > public private(set) string $name; > > public string $name { > private set; > } > ``` > > ## 3) "`Prefix-style` doesn't presume a connection with hooks" > > As noted above in "Interaction with hooks", visibility controls exist > independently of hooks. > > I agree, but with Property Hooks, this should now define the overall > visibility only. Like a bigger gate that you open, and there are other > doors defining the visibility of the operations get, set (hooks). > > > In fact, as implemented, they don't interact at all. Using hook syntax > for visibility controls is therefore surprising and confusing. > > Why "surprising and confusing"? I see hooks as a different kind of > function/method. > Property Hooks RFC shouldn't pass without requiring hook parentheses, for > any hook when the property is not abstract. The `$value` in the `set` hoo= k > seems to come out of nowhere to some people (the exception is for hooks > declared on an abstract property which you can define without parameters > and thus you are free to define whatever parameters you want on the > concrete property). > > When you define a method in PHP, it should be possible to omit the > "function", but the parameters should be required because that's the natu= re > of a function/method: to have parameters. > > ## 4) "It's non-obvious in `Hook-embedded-style` what hook behavior shoul= d > be implied" > > > ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an est= ablished fact of > the language. However, if the hook-style syntax is used for visibility: > > ```php > class A > { > public array $arr { protected set; } > } > > class B extends A > { > public function add(int $val) > { > // Should this be legal? > $this->arr[] =3D $val; > } > } > > $b =3D new B(); > > $b->add(5); > ``` > First of all: non-abstract property hook must have a body. > Second: when asymmetric visibility is explicit, it means that symmetric > visibility is implicit: a declared hook that does not have declared > visibility has the same general visibility as the property, in this case: > public. > > Third: > There's another limitation on hooks here that makes things a bit > confusing: there's a missing hook for a specific operation because you ca= n > clearly separate the `set` from the `push` operation... > > Solution: > ```php > abstract class A > { > abstract public array $arr { > push; // Hook available only for "array" type properties only; > public visibility > private set; > } > } > > class B extends A > { > public array $arr { > push ($value) { // `public push ...` here is redundant > // Mandatory to implement logic here. > } > private set ($value) { > // Mandatory to Implement logic here. > } > } > > public function __construct () > { > // Legal =E2=9C=85 (set hook is protected) > $this->arr =3D [1]; // call set hook > } > public function add(int $value) > { > // Legal =E2=9C=85 (push hook is public) > $this->arr[] =3D $value; // call push hook > } > } > > $b =3D new B(); > > $b->add(5); > $b->arr; // Legal =E2=9C=85 (Inherited from the general visibility that i= s public) > $b->arr =3D [1, 2, 3]; // Fatal error =E2=9D=8C - access to set hook is p= rivate only > $b->arr[] =3D 4; // Legal =E2=9C=85 - call public push hook > ``` > > My point: `Prefix-style` is not future-proof > ## 1) The `Prefix-style` is not compatible with new hooks > If more hooks are added in the future, such as the `push` hook for arrays > or even a hook that is compatible with all types such as `init`, > `Hook-embedded-style` will become compatible, but `Prefix-style` not. > > ## 2) Hook overloading > If hook overloading is added in the future, `Prefix-style` would not be > supported to have this granular visibility into operations. For example, = it > might be possible to add a public hook and a protected hook for the same > operation, where one would be triggered if the operation occurred from > outside the class, and the other if the operation occurred from inside th= e > class. > Em 10 de jun. de 2024 13:15 -0300, Tiffany > escreveu: > > > On Wed, May 29, 2024, 2:16=E2=80=AFPM Larry Garfield > wrote: > >> As promised, Ilija and I offer this revised version of asymmetric >> visibility. >> >> https://wiki.php.net/rfc/asymmetric-visibility-v2 >> >> It's still essentially the same as last year's version, but with a few >> adjustments and changes: >> >> * readonly properties are now supported in a logical fashion. >> * We've brought back the abbreviated form, as public-read, something els= e >> set is the most common use case. >> * The section on magic methods has been greatly simplified. The >> implementation itself hasn't changed, but the explanation is a lot less >> confusing now. >> * We've explained how aviz interacts with hooks (they don't, really) and >> with interface properties (in the obvious way), which didn't exist at th= e >> time of the last draft. >> * We've added a section with examples of how aviz is a concrete >> improvement, even in a world with readonly and hooks. >> * We've added a section discussing why the prefix-style syntax was chose= n. >> >> *dons flame retardant suit* >> >> -- >> Larry Garfield >> larry@garfieldtech.com > > > Sending an email to quickly enable a new mailing list subscriber to engag= e > in the conversation. > > --000000000000d9cdb8061a8ed7bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You guys=C2=A0are killing PHP. There is a lot of work to b= e done on the engine to modernize it and make it more robust and sturdy. Sh= it like this just adds more complexity to PHP in the name of convenience. I= think this is my cue to explore other languages for handling requests
<= /div>
O= n Mon, Jun 10, 2024 at 1:18=E2=80=AFPM Rodrigo Vieira <rodrigo.vieira92@outlook.com> wrote:<= br>
I didn't like the `Prefix-style` syntax. I prefer the= `Hook-embedded-style` syntax. First let's look at the counterpoints of= the `Prefix-style` syntax:

## 1) "`Prefix-style` is more visually scannable"
> The set visibility is 10 lines away from the get visibility!

Solution:
```php
class HookEmbeddedStyle
{
=C2=A0=C2=A0 =C2=A0public string $phone {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->phone =3D implode(= '', array_filter(fn($c) =3D> is_numeric($c), explode($value))) =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0get {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!$this->phone) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return '&#= 39;;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ($this->phone[0] =3D= =3D=3D 1) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 'US= ' . $this->phone;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 'Intl +' . $t= his->phone;
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0}
}
```
The set visibility is not 10 lines away from the get visibility if you put = it at the top. For me this is about code convention, not about syntactic st= ructure:
only put the hook with explicit visibility at the top, when some of the hoo= ks do not have explicit visibility!

## 2) "`Prefix-style` is shorter"
```php
public private(set) string $name;

public string $name { private set; }
```

Irrelevant to consider 1-2 characters.
If you break the lines needed for the hook block, the line (the horizontal = size) is smaller when using `Hook-embedded-style` and in my opinion it is m= ore readable because there is less information per line:
```php
public private(set) string $name;

public string $name {
=C2=A0 =C2=A0private set;
}
```

## 3) "`Prefix-style` doesn't presume a connection with hooks"= ;
> As noted above in "Interaction with hooks", visibility contr= ols exist independently of hooks.

I agree, but with Property Hooks, this should now define the overall visibi= lity only. Like a bigger gate that you open, and there are other doors defi= ning the visibility of the operations get, set (hooks).

> In fact, as implemented, they don't interact at all. Using hook sy= ntax for visibility controls is therefore surprising and confusing.

Why "surprising and confusing"? I see hooks as a different kind o= f function/method.=C2=A0
Property Hooks RFC shouldn't pass without requiring hook parentheses, f= or any hook when the property is not abstract. The `$value` in the `set` ho= ok seems to come out of nowhere to some people (the exception is for hooks = declared on an abstract property which you can define without parameters an= d thus you are free to define whatever parameters you want on the concrete = property).

When you define a method in PHP, it should be possible to omit the "fu= nction", but the parameters should be required because that's the = nature of a function/method: to have parameters.

## 4) "It's non-obvious in `Hook-embedded-style` what hook behavio= r should be implied"

> ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an es= tablished fact of the language. However, if the hook-style syntax is used f= or visibility:

```php
class A
{
=C2=A0=C2=A0 =C2=A0public array $arr { protected set; }
}
=C2=A0
class B extends A
{
=C2=A0=C2=A0 =C2=A0public function add(int $val)
=C2=A0=C2=A0 =C2=A0{
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Should this be legal?
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0$this->arr[] =3D $val;
=C2=A0=C2=A0 =C2=A0}
}
=C2=A0
$b =3D new B();
=C2=A0
$b->add(5);
```
First of all: non-abstract property hook must have a body.
Second: when asymmetric visibility is explicit, it means that symmetric vis= ibility is implicit: a declared hook that does not have declared visibility= has the same general visibility as the property, in this case: public.

Third:
There's another limitation on hooks here that makes things a bit confus= ing: there's a missing hook for a specific operation because you can cl= early separate the `set` from the `push` operation...

Solution:
```php
abstract class A
{
=C2=A0=C2=A0 =C2=A0abstract public array $arr {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0push; // Hook available only for "arr= ay" type properties only; public visibility
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set;
=C2=A0=C2=A0 =C2=A0}
}

class B extends A
{
=C2=A0=C2=A0 =C2=A0public array $arr {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0push ($value) { // `public push ...` here = is redundant
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Mandatory to implement lo= gic here.
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set ($value) {
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Mandatory to Implement lo= gic here.
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0}

=C2=A0=C2=A0 =C2=A0public function __construct ()
=C2=A0=C2=A0 =C2=A0{
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Legal =E2=9C=85 (set hook is protected)=
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0$this->arr =3D [1]; // call set hook =C2=A0=C2=A0 =C2=A0}
=C2=A0=C2=A0 =C2=A0public function add(int $value)
=C2=A0=C2=A0 =C2=A0{
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Legal =E2=9C=85 (push hook is public) =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0$this->arr[] =3D $value; // call push h= ook
=C2=A0=C2=A0 =C2=A0}
}

$b =3D new B();

$b->add(5);
$b->arr; // Legal =E2=9C=85 (Inherited from the general visibility that = is public)=C2=A0
$b->arr =3D [1, 2, 3]; // Fatal error =E2=9D=8C - access to set hook is = private only
$b->arr[] =3D 4; // Legal =E2=9C=85 - call public push hook
```

My point: `Prefix-style` is not future-proof
## 1) The `Prefix-style` is not compatible with new hooks
If more hooks are added in the future, such as the `push` hook for arrays o= r even a hook that is compatible with all types such as `init`, `Hook-embed= ded-style` will become compatible, but `Prefix-style` not.

## 2) Hook overloading
If hook overloading is added in the future, `Prefix-style` would not be sup= ported to have this granular visibility into operations. For example, it mi= ght be possible to add a public hook and a protected hook for the same oper= ation, where one would be triggered if the operation occurred from outside = the class, and the other if the operation occurred from inside the class.
Em 10 de jun. de 2024 13:15 -0300, Tiffan= y <tiffa= ny.k.taylor@gmail.com> escreveu:

On Wed, May 29, 2024, 2:16=E2=80=AFPM= Larry Garfield <larry@garfieldtech.com> wrote:
As promised, Ilija and I = offer this revised version of asymmetric visibility.=C2=A0

https://wiki.php.net/rfc/asymmetric-visi= bility-v2

It's still essentially the same as last year's version, but with a = few adjustments and changes:

* readonly properties are now supported in a logical fashion.
* We've brought back the abbreviated form, as public-read, something el= se set is the most common use case.
* The section on magic methods has been greatly simplified.=C2=A0 The imple= mentation itself hasn't changed, but the explanation is a lot less conf= using now.
* We've explained how aviz interacts with hooks (they don't, really= ) and with interface properties (in the obvious way), which didn't exis= t at the time of the last draft.
* We've added a section with examples of how aviz is a concrete improve= ment, even in a world with readonly and hooks.
* We've added a section discussing why the prefix-style syntax was chos= en.

*dons flame retardant suit*

--
=C2=A0 Larry Garfield
=C2=A0 larry@garfieldtech.com

Sending an email to quickly enable a new mailing list sub= scriber to engage in the conversation.
--000000000000d9cdb8061a8ed7bb--