Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119056
MIME-Version: 1.0
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <831b9906-dc0c-420c-b22f-8a0cc8a1ad64@app.fastmail.com> <434BDABD-8551-46C8-98EC-8CA87952AE25@gmail.com>
 <cb2ca327-fc62-4c2d-bde1-f95d50f53c49@app.fastmail.com> <E87781C5-4C07-4C47-93D8-0188794D0D0F@koalephant.com>
In-Reply-To: <E87781C5-4C07-4C47-93D8-0188794D0D0F@koalephant.com>
Date: Wed, 30 Nov 2022 08:41:29 +0000
Message-ID: <CAAwdEzD5ZpJ+DTK=NcbiDdZPhvss4UgLYq3cVUd-D3Q2BOARJA@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cd3d9405eeac12c2"
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000cd3d9405eeac12c2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 30, 2022, 05:25 Stephen Reay <php-lists@koalephant.com> wrote:

>
>
> > On 30 Nov 2022, at 08:27, Larry Garfield <larry@garfieldtech.com> wrote=
:
> >
> > On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote:
> >
> >> In the RFC, section Permitted visibility
> >> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility
> >> <https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility>)=
:
> >>> The set visibility, if it differs from the main (get) visibility, MUS=
T
> be strictly lesser than the main visibility. That is, the set visibility
> may only be protected or private. If the main visibility is protected, se=
t
> visibility may only be private. Any violation of this rule will result in=
 a
> compile time error.
> >>>
> >> The first sentence does not forbid `public public(set)`, or `protected
> >> protected(set)`, etc. (the `set` visibility does not differ from the
> >> main visibility), but the rest of the paragraph does not allow it. Tha=
t
> >> should be clarified.
> >
> > Er.  That's exactly what it says: "strictly lesser" than the main
> visibility.  The lines after are just restating it.  "public public(set)"
> is not allowed.
> >
> > (We may relax that in the future to make it compatible with readonly,
> but that's for later.)
> >
> >>
> >> (Because forbidding `public public(set)`, etc., makes it slightly more
> >> cumbersome to explain the rules, I am slightly in favour not to forbid
> >> it.)
> >>
> >>> There is one exception, that of a private readonly property. That
> would technically expand to private private(set) readonly, which is allow=
ed.
> >>
> >> That sentence should be deleted, as `readonly` is now forbidden.
> >
> > Good catch, fixed.  Thanks.
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
> Hi Larry,
>
> Thank you for clarifying the setter behaviour in more explicit terms, but
> I have to say I=E2=80=99m quite disappointed in this continued =E2=80=9Cu=
se the logic of
> readonly to apply to something that is explicitly not readonly=E2=80=9D -=
 this is
> even more stark now that you=E2=80=99ve explicitly made them mutually exc=
lusive
> behaviours.
>
> I=E2=80=99m generally very in favour of maintaining consistency, but this=
 seems
> like it=E2=80=99s using technical consistency as an excuse to justify uni=
ntuitive
> behaviour that breaks consistency in another, much more obvious way.
>
>
> Can you explain why it makes more sense to maintain consistency with
> =E2=80=9Creadonly=E2=80=9D than it does to maintain consistency with the =
existing =E2=80=9C__set()=E2=80=9D
> behaviour for properties, particularly now that you=E2=80=99ve indicated =
these
> features (asymmetric visibility and readonly) are mutually exclusive?
>
> While it=E2=80=99s stated multiple times that =E2=80=9Creadonly=E2=80=9D =
introduced a limited form
> of asymmetric visibility, and thus this is a continuation, in terms of
> intuitiveness, the existing __set() rules are very easy to comprehend eve=
n
> with readonly:
>
> - if the property is declared as public, __set() is never called; if it=
=E2=80=99s
> declared as protected, __set is called when the property is accessed from
> outside that class or it=E2=80=99s hierarchy. Yes, I know that readonly i=
mposes an
> implicit visibility difference - but that is essentially an implementatio=
n
> detail, from the point of view of the userland developer, it=E2=80=99s no=
t a clear
> statement of intended behaviour on their part, expressed through the code
> as written.
>
> For example, with `public readonly int $foo` it=E2=80=99s quite obvious w=
hy
> __set() isn=E2=80=99t called, using the exiting well-understood logic: it=
=E2=80=99s a
> public property. PHP applies a kind of asymmetric visibility to the
> property behind the scenes, but that isn=E2=80=99t what the developer dec=
lared,
> it=E2=80=99s the implementation. This behaviour matches that of regular,
> non-readonly fields: when the field is declared public (or has implicit
> public visibility) __set() is never called.
>
> If we make that field protected, __set() will be called when the property
> is written to from outside the class, regardless of whether it=E2=80=99s =
readonly
> or not.
>
>
> What you=E2=80=99re proposing changes that, in a way that is completely
> unintuitive: when attempting to *write* data to a property that is marked
> as protected(set), the __set() method will not be called.
>
>
> So please, can you explain to me why consistency with an implementation
> detail of readonly properties is more important than consistency with
> declared developer intention for regular properties via the magic setter
> method?
>
>
Hey, Stephen, Larry,
Just clarifying how I see it:

Practically, the asymmetric visibility for properties is not more or less
than asymmetric write-access for properties.
That is what is implemented, that is what other languages have as well and
this is what's needed.
Of course, except for relation with __set(), unset() and other php
specials, it wouldn't make a difference.

If you think it like this, that property is actually visible but only there
is a restriction on writing it, you would probably agree that __set()
should not be called.

And given that, for clarity, I would be happy if the word visibility would
be changed in the rfc with write-access in various places, including the
rfc name.
But I don't think it's very important, as long as I've understood the
behavior and I can easily explain it going forward.

Regards,
Alex



>
> Cheers
>
> Stephen
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000cd3d9405eeac12c2--