Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123469 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 6DEFE1A009C for ; Fri, 31 May 2024 12:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1717157163; bh=lisqeLSu//U6EUi/wQXj1hFoqic3+FkrU8hz5YLiTL0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=m0Fk6GC2Vh+dV05tW9lm+fhn2ljYHB0LEyILG8wQ/CgrICuD8vPCb1i3MTAy5Ca9W k394G2vm961t9lgqIk1lIqtndwxTuuMszqwM0NWqhym0O2byBqdXdLHxVvtvn/CS9a YiWJOavXS6MN03jqP9pGwSI7Kg5yqKKvyh+LB0UHV9x40AO/11nAGXqa/M/kClyLP2 HjKuuZe1hL7ICek3I1n1pTdtaB/UmJWXBjErH5M/KN+wLbgYF7pAhebzUyRPQgjB/N qfEoT5HnyaeHt5fHo8n/Pzpbx0d5vYWXJo/2gLyyjeJJcjYcq5PuxZyDQbZZextQUt dt2bUQCSE8DGA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D22F5180069 for ; Fri, 31 May 2024 12:06:01 +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_H3,RCVD_IN_MSPIKE_WL, 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-oo1-f44.google.com (mail-oo1-f44.google.com [209.85.161.44]) (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 ; Fri, 31 May 2024 12:06:01 +0000 (UTC) Received: by mail-oo1-f44.google.com with SMTP id 006d021491bc7-5b9817a135aso1055316eaf.0 for ; Fri, 31 May 2024 05:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717157099; x=1717761899; 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=lisqeLSu//U6EUi/wQXj1hFoqic3+FkrU8hz5YLiTL0=; b=AA0yHMSz2Jm3hLmtxMtt193PY8aGn85zjuF7MoBOso95srCQz/6C0dMx/vJdbz0DZ0 ACBnWs0gwIRnfT1lPAYHV935R1Z0QqJ4BCLIGARPjWrrC/PqNGQKIWS3VPJKpKh3yIyX ozLOT+b6eDZrR4wD96DRJlV6OCnVt3kGE/7aXp0bxIhi1bnA0u3LLoGNR3KxnG9/wdYA mRilwLMUeOlnDi9bMMM/6RtZ6iNqsAehqwdwEACQq4zgpflGhhfsRZtbMo/yDHDf2mme 3STgpsPjgpB4FpKzDLLCer8pL0MY4i67qwGvKg/qVSUsBuTpMLfYO9Y1VoibkoXfyg2d E8XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717157099; x=1717761899; 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=lisqeLSu//U6EUi/wQXj1hFoqic3+FkrU8hz5YLiTL0=; b=PPnZO45wCn1YSdgs2k2GB8+bFVmoUu3n3dHOTqQUsVkn3icEYuvajkvcFgBPtD4+XM ZmpSlS8kXHiQMSFFLEavmlVz2hF6FfRAVWjLVafP/gvM9qF/bp6D9eVfwNLd8iqPk/uJ 6Y901qaJ3igmDN//DgFR0T3Yb0OUXT0TOjrLavw0jWTyZIS7PIU5jcPANYhnXXVMjLfH 1ImbVpBdj9XkJKFXiHbaiG4APNrbd7GembcXvBBWjj8q2YL35/jLYBM1xLd6cedf949Z hEK9sa2GhaB3lL/VkZNqoE8MS9y+KzJ9lnSMos4v0kwdZqYV2euSBxD8bL3TB9/kBzz/ K9xQ== X-Forwarded-Encrypted: i=1; AJvYcCU31f3mphpta0XRCYOKLQFuSOK1UyKrQJNHD09HqVUvChVFyTST779NlTpqYO6cptJtfUI0ypuZMGaoUwkvBlXEkQEG5GZcBA== X-Gm-Message-State: AOJu0YzIIHTd2qCUj9hUAJYtxXluKgg3NwyKTsiY7FOdR3X/J0K/yEIg 5D+MO2tpnBDMYv38EsCYOlvjiZ8T70FnSUsl50EZDgpqB5ggApSN/eyEcr8sTie/AqzpKnaI1mR 3EBBH7+hszmL6y47uxM43nODcmpSAkZZPWi0= X-Google-Smtp-Source: AGHT+IGjuEMQIfVCqAua+rhjtibRDPu4ioBYAiqFAXkaM48NNUhH02zX6v34gedRaKV1OGKedaFzYigNgT9upqJI73s= X-Received: by 2002:a05:6358:39a6:b0:186:1f9a:1771 with SMTP id e5c5f4694b2df-19b490c6460mr207960455d.29.1717157098783; Fri, 31 May 2024 05:04:58 -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: Fri, 31 May 2024 15:04:40 +0300 Message-ID: Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2 To: Claude Pache Cc: Derick Rethans , php internals Content-Type: multipart/alternative; boundary="000000000000e590440619beca20" From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=) --000000000000e590440619beca20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 31, 2024 at 10:30=E2=80=AFAM Claude Pache wrote: > > > Le 30 mai 2024 =C3=A0 17:07, Derick Rethans a =C3=A9crit= : > > > Now, if I define the property as public private(set) with similar > intentions, to make sure that there is no way for external scope or > extending classes scope to write to the property, while allowing > reading from external scope (or extending classes scope). > > But the problem is that an extending class can define the property as > public protected(set), and that will easily allow the property that I > wanted to make sure it is private for writing to be changed by an > extending class to be protected. > > > public private(set) properties aren't really private, so you don't get > the shadowing, but you do have a point wrt to the expectation that an > inherited class can't easily override the private(set) part (with > protected(set) or public(set)). > > > > Note that the issue already exists today with readonly properties: those > are basically private(set); but if you redeclare a non-private readonly > property in a subclass, you can in fact initialise it from the subclass > bypassing the initial private(set) restriction of the superclass: > https://3v4l.org/9AV4r > Yes, thank you; that's a good point. Seems like another issue with readonly, but then again, the private(set) part of readonly is not really explicitly designed, I guess. > > If you want a property not to be overridable, end of story, you can mark > it as `final` (the final marker for properties was added as part of the > hooks RFC, but it works also with non-hooked properties). > Yes, it seems like a good enough option, and use "final public private(set)" to ensure only the current class will be able to set the value. If we all agree, I think this should be documented in the RFC. There is another small problem, I think, with "final" modifier not being allowed for constructor-promoted properties. And maybe we can have this fixed in the current RFC if this ends up being "the correct" way to define public-read private-write properties. Regards, Alex --000000000000e590440619beca20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, May 31, 2024 at 10:30=E2=80=AFAM = Claude Pache <claude.pache@gma= il.com> wrote:


Le 30 mai 2024 =C3=A0 17:07, Derick R= ethans <derick@php.n= et> a =C3=A9crit :


Now, if I define the property as public private(set) with similar=C2=A0
intentions, to make sure that there is no way for exte= rnal scope or=C2=A0
extending classes scope to write to the= property, while allowing=C2=A0
reading from external scope= (or extending classes scope).

But the problem is that an extending = class can define the property as=C2=A0
public protected(set= ), and that will easily allow the property that I=C2=A0
wan= ted to make sure it is private for writing to be changed by an=C2=A0<= /span>
extending class to be protected.

public private(set) propertie= s aren't really private, so you don't get=C2=A0=
the shadowing= , but you do have a point wrt to the expectation that an=C2=A0=
inheri= ted class can't easily override the private(set) part (with=C2=A0=
protected(set) or public(set)).
=


Note that the issue already exists= today with readonly properties: those are basically private(set); but if y= ou redeclare a non-private readonly property in a subclass, you can in fact= initialise it from the subclass bypassing the initial private(set) restric= tion of the superclass:=C2=A0https://3v4l.org/9AV4r

Yes, thank you; that's a good point.
Seems like another is= sue with readonly, but then again, the private(set) part of readonly is not= really explicitly designed, I guess.
=C2=A0

If you want= a property not to be overridable, end of story, you can mark it as `final`= (the final marker for properties was added as part of the hooks RFC, but i= t works also with non-hooked properties).

=
Yes, it seems like a good enough option, and use "final pub= lic private(set)" to ensure only the current class=C2=A0will be able t= o set the value.
If we all agree, I think this should be document= ed in the RFC.

There is another small problem, I t= hink, with "final"=C2=A0modifier not being allowed for constructo= r-promoted properties.
And maybe we can have this fixed in the cu= rrent RFC if this ends up being=C2=A0"the correct" way to define = public-read private-write properties.

Regards,
Alex

--000000000000e590440619beca20--