Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124199 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 BABAD1A009C for ; Wed, 3 Jul 2024 14:33:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720017290; bh=qm79aUynRMTWfALIoC4+Qm8G0DT6sS4DevmXgM0usIc=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=h4eg+1y+AxpR+dVRrE5NtUIoGrjlwdFT/K3Fn/Js0maBnb9TVABduYi1LCPjQrC+0 zhQp6MlFAvV+p81D66XOYUdK3w6aL60tHDM6RFrFylA0gzXeZOkIsib3R1AsI7e0jc hgRgtFM8vXoq7gbOhrPj4uH4Uzs6XquvKplz5y0tm7gdsmGtVyHP4QO3izooxROyUm KyPqScmxJTJy0rmByujjylWe1Y4L0bS7uwlhK+/uslIP8btX7omDWvqXYV5ExxHaj1 96rtwRNVmNFask+G0pnT+ocTPCxs4VILkSelgsGWfwE+hbU0uNovPXAmSLabOPUFhF Qy7bMEOWDZmLw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B583118054A for ; Wed, 3 Jul 2024 14:34:49 +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.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,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 fhigh5-smtp.messagingengine.com (fhigh5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 3 Jul 2024 14:34:49 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id EAD9F11400E9; Wed, 3 Jul 2024 10:33:26 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Wed, 03 Jul 2024 10:33:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1720017206; x= 1720103606; bh=i+O0PYvl8UjOljf6F8sRGvorOVWKrBviTRhQ5GA8DMk=; b=t yDz9O/83ka2/jpLQ1DR0KwGrfzNUzvwjsCK01AWNpVh0AEp5K+aY/8Yc0CMR/kIJ h8Rh59kdNhht/P5PkoeF5AvAL9M5bPCUsuRn5ucRtJBc7n49sGOZ2GdQcc8YwDw2 kU3nC8r69uCrqkCReHwDgUUIRt0gdWLtx/c3GhHwx1MLvc4P6txkX8of1y20XSZ6 YP5fh+Dfzv2TvYftsOBl7tNmqvsa/4QHvEIUXROuT4OWYg4Gz7r34qhVtcIk0qAh UeOtGSNjczXx+7EnuiVbFYKOis3T2BX+e2e9h4e7ItGZL/j597X80u0LWvnTU1LA Nlo+GgtkjVx7RuIRmybXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1720017206; x=1720103606; bh=i+O0PYvl8UjOljf6F8sRGvorOVWK rBviTRhQ5GA8DMk=; b=PvIj0UAxcEnRwzr3n/jH9gQIPP208t/o3y5nf+4Zg0A2 6EU7wiuoF571j4trWFxfnCCnr9gpENFZb+6qni53nDDyQKHfdYwH6+pdob6plycE UCkotedwUIRSxEVV4M1u1CASXtTMDLGJXTAYUUXqgG1ZFusIUSth0iWY9wqtAcAk nb/img6fkr2nh6xZQhI1v81EoY4mCJOfwhORVAyb8ap2n5E5h+Q94BOVVBYLKA5S D7NU8mO33IQEIqK3/bPqn8HbDRrl+zrunwcPW0T20wlflYLKX4GuTr7UG3K1COug ysXONqHVC9dsQ8z0/D4jWIjHnihakN6BqlyPbEzgTw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudejgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdftohgs ucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrg htthgvrhhnpedvheekteelveetfeevgeekgfffvdeuhfelveehvdetiefggedtfeejheet gffhueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7075F15A0092; Wed, 3 Jul 2024 10:33:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <8db7f4f3-d0ed-4db3-8520-a76b2c4025c4@app.fastmail.com> In-Reply-To: <02de79f3-c323-4e54-ba26-e213d9b4c65d@app.fastmail.com> References: <8A3C2FDA-60DF-45A1-BA9D-11B6FB6F755C@gmail.com> <557008ce-30c4-4002-b731-1faabe487e64@app.fastmail.com> <063761C9-3DAE-4F3C-8279-F2B1636EF953@gmail.com> <02de79f3-c323-4e54-ba26-e213d9b4c65d@app.fastmail.com> Date: Wed, 03 Jul 2024 16:33:04 +0200 To: "Claude Pache" Cc: "Larry Garfield" , "php internals" Subject: Re: [PHP-DEV] [RFC] Property Hook improvements Content-Type: multipart/alternative; boundary=bc154dabc15e4ab8b84936a48452034a From: rob@bottled.codes ("Rob Landers") --bc154dabc15e4ab8b84936a48452034a Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2024, at 16:22, Rob Landers wrote: >=20 >=20 > On Wed, Jul 3, 2024, at 15:29, Claude Pache wrote: >>=20 >>=20 >>> Le 3 juil. 2024 =C3=A0 14:42, Rob Landers a =C3=A9= crit : >>>=20 >>> On Wed, Jul 3, 2024, at 14:28, Claude Pache wrote: >>>>=20 >>>>=20 >>>>> Le 3 juil. 2024 =C3=A0 11:54, Claude Pache a =C3=A9crit : >>>>>=20 >>>>>=20 >>>>> 2. As for readonly, I think that the invariant it is supposed to p= rovide should be enforced as strictly as possible. It means that `readon= ly` is only acceptable if there is no `get` hook. >>>>=20 >>>> Hi, >>>>=20 >>>> One more thing, why I think that we should be strict here. It is no= t just for preventing the user to write *dumb* code, it is also for prev= enting them to write *creative* code, e.g. >>>>=20 >>>> ```php >>>> class doc { >>>> public readonly int page { >>>> get =3D> $this->page + $this->offset; >>>> } >>>> private int $offset =3D 0; >>>> public function __construct(int $page) { >>>> $this->page =3D $page; >>>> } >>>> public function foo() { >>>> // $this->offset may be adjusted here >>>> } >>>> } >>>> ``` >>>>=20 >>>> =E2=80=94Claude >>>=20 >>> I don't see anything wrong with that code. $page doesn't say "immuta= ble" it says "readonly", as in "cannot write to". >>>=20 >>> =E2=80=94 Rob >>=20 >> The fact you don=E2=80=99t see anything wrong is *precisely* the issu= e. According to the original RFC [1], the intention of readonly properti= es was immutability, not just non-writability. For the weaker case of no= n-writability, it was explicitly mentioned the possibility of (future) a= symmetric property visibility. >=20 > That was before properties could be functions? Now I suppose we have t= o decide if the definition of read-only doesn't mean read-only, but immu= tability; despite the original intention. >=20 >>=20 >> That said, I agree that =E2=80=9Cimmutable=E2=80=9D would have been a= better word choice than =E2=80=9Creadonly=E2=80=9D for conveying the or= iginal intention. We could also ignore the original intention and reinte= rpret the feature in case everyone agrees (personally, I prefer the orig= inal intention, but I won=E2=80=99t fight for that). >=20 > Agree. I just wanted to point out that there were two interpretations:= the English definition, and the original intention of the RFC. >=20 > =E2=80=94 Rob In better words, as a dev, I don't care which interpretation is chosen, = as long as it is consistent. =E2=80=94 Rob --bc154dabc15e4ab8b84936a48452034a Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=

On Wed, Jul 3, 2024, at 16:22, Rob Landers wrote:


On Wed, Jul 3, 2024, at 15:29, Claude Pache wrote:
<= /div>


Le 3 juil. 2024 =C3=A0 14:42, Rob Landers <rob@bottled.codes> a = =C3=A9crit :

On Wed, Jul 3, 2024, = at 14:28, Claude Pache wrote:


Le 3 juil. 2024 =C3=A0 11:54, Claude Pac= he <claude.pache@gmail.com> a =C3=A9crit :


= 2. As for readonly, I think that the invariant it is supposed to provide= should be enforced as strictly as possible. It means that `readonly` is= only acceptable if there is no `get` hook.
<= br>
Hi,

One more thing, why I thi= nk that we should be strict here. It is not just for preventing the user= to write *dumb* code, it is also for preventing them to write *creative= * code, e.g.

```php
clas= s doc {
    public readonly int page {
=
        get =3D> $this->page + $this->= offset;
    }
    privat= e int $offset =3D 0;
    public function __const= ruct(int $page) {
        $this->pa= ge =3D $page;
    }
    = public function foo() {
        // $th= is->offset may be adjusted here
    }
}
```

=E2=80=94Claude<= br>

I don't se= e anything wrong with that code. $page doesn't say "immutable" it says "= readonly", as in "cannot write to".

=E2=80=94 Rob

The fact you don=E2=80=99t see anything wrong is *p= recisely* the issue. According to the original RFC [1], the intention of= readonly properties was immutability, not just non-writability. For the= weaker case of non-writability, it was explicitly mentioned the possibi= lity of (future) asymmetric property visibility.
<= div>
That was before properties could be functions? Now I = suppose we have to decide if the definition of read-only doesn't mean re= ad-only, but immutability; despite the original intention.


That said, I agree that =E2=80=9Cimmut= able=E2=80=9D would have been a better word choice than =E2=80=9Creadonl= y=E2=80=9D for conveying the original intention. We could also ignore th= e original intention and reinterpret the feature in case everyone agrees= (personally, I prefer the original intention, but I won=E2=80=99t fight= for that).

Agree. I just want= ed to point out that there were two interpretations: the English definit= ion, and the original intention of the RFC.

=E2=80=94 Rob

In better words, as a dev, I don't care which interpretation is = chosen, as long as it is consistent.

=E2=80=94 Rob
--bc154dabc15e4ab8b84936a48452034a--