Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109109
MIME-Version: 1.0
References: <CAH5C8xVY5SFLBt2jZ9dx93rQC_Xjp4pKZJ+MP=K1TbjyDi9CDA@mail.gmail.com>
 <CAOWwgpmBMB3iPyg+GoL=39u68yUX1ERCs2-csENTJ04PmS4xMA@mail.gmail.com>
 <CAH5C8xW0KBj5qYet=nrMrAz_XNViK-4KyMZMQMkxU5veXXVxFg@mail.gmail.com> <CAOWwgpk6cFEZ_WQopYG+7=AwvuUAg02opWt1bH=tdSqu5vOF1Q@mail.gmail.com>
In-Reply-To: <CAOWwgpk6cFEZ_WQopYG+7=AwvuUAg02opWt1bH=tdSqu5vOF1Q@mail.gmail.com>
Date: Tue, 17 Mar 2020 19:07:52 +0100
Message-ID: <CAH5C8xXrVAdDzJrTaknuLeAbhhB2GYZZw1toS553AXUycpq7VA@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002bef8105a110d1e6"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000002bef8105a110d1e6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Both proposals relate a lot to each other: it's one or another, both cann=
ot
> coexist: there is only one meaning for the "readonly" keyword once it's
> bound to some interpretation.


You are right in the sense that the two proposals can't use the same
keyword.
However, I believe we both agree that the two features themselves are not
exclusive to each other (although some argue if it's worth to have both).
So I don't understand why you would insist on using the same keyword
a "write-once" property would have according to my proposal.

I mean, if your end goal is to offer a simpler variant of a property
accessor feature
then in case of a "write-once" property the syntax could be (copied from
someone's
tweet):

readonly public private $foo;


Not that I like this idea, but it could mean that the property can be read
in the public
scope, and written only once in the private scope. I'm sure there are
other, more
explicit ways to express the same intention.

I think it's clear after the prior example that there is a place for both
of our features.
I understand though that you don't feel the need to be that strict in the
private/protected
scope (while I would most probably vote against all variants of property
accessors).

What I'd like to achieve is to offer strong guarantees - actually, as
strong as a type-system
level one - about that my properties can't change over time, as well as
being able to reason
about the (non-internal) mutability of my properties just by looking at the
type.

At this point I'd like to repeat one of my previously mentioned arguments
for the feature:
if we have an immutable PSR-7 that is used all over the PHP ecosystem, and
we also have
lots of people who wish for more type-level strictness by using immutable
DTOs or VOs,
why don't we provide a proper way to achieve immutability? If there is such
a need
then I think we should react. Even more so, because the same feature is
available in other
languages where we usually copy from, so it wouldn't even be without
precedents.
(Just to be clear: I don't think that we have to copy everything from Java
or C#. :) )

Also, Marco was wondering somewhere on Twitter if it would be possible to
perform some
engine-level optimizations of "write-once" properties? I'm also not sure
but I'd
be very curious about its feasibility. Hopefully, Nikita or Dmitry can
answer it. :)

Thus the RFC doesn't address the currently most common way of writing
> immutable VOs I fear.


Yes, VOs that currently use cloning for mutation has to change their code
to create
a new instance if they have "write-once" properties. At least it's the
situation
according to the current proposal. I'll copy-paste an earlier answer of
mine here
what ideas were brought up to solve the cloning issue:

... Actually, I even had a short discussion with Nikita about the topic. He
> proposed the

following syntax (which is inspired by Rust):
> public function withFoo(FooT $foo): static {
> return new static { foo =3D> $foo, ...$this };
> }
> My idea was very similar, but it affects cloning:
> $self =3D clone $this with { foo =3D> $foo, bar =3D> $bar, ... }


Do you have any other ideas or comments about the two proposals? Another
reason
why I wanted to omit this from the current proposal is because that way the
RFC
would have included even more things to debate on and an even bigger
"attack surface".
We didn't want property initializers as proposed by the previous RFC, and
we'd probably
debate for quite some time on the clone syntax I proposed... Let's discuss
bigger
things separately instead as how we did in case of nullable types or the
void type.
(Please note that I wouldn't like to wait for one or more releases)

Note that I'm just arguing that the extra guarantee you look for might not
> be worth the downside.


I understand your point of view. However, I'm not sure what you mean by the
downsides? I believe you might think about cloning for one, but what are th=
e
others? Maybe that a "write-once" property must have a type and can't have
a default value?

I think the second one is not something that people in practice would have
to face.
We have constants for exactly the same purpose. This way, we can postpone
the decision about what to do with default values until it's necessary to
decide.
I also wasn't very happy to add a special rule like that but it was the mos=
t
responsible thing to do I think.

Besides, I'd call the requirement to have typed properties in order to be
eligible for
the "readonly" keyword a good thing. Having more types is good, right? :)
But half-joking aside, there is just no way to extend "write-once"
semantics to
untyped properties. If anyone can come up with a sane way then I'd would be
very
happy to push it. Of course, you can call this restriction a conceptual
issue, but
I think we stayed within the limitations of the current type-system to
achieve the
goal I set without adding more quirks and weird workarounds to the
language...
Yes, for the price of special casing this feature for typed properties...

the RFC doesn't mention anything about Reflection-based mutability


You are right, a mention could have been added to the RFC. If I'm allowed t=
o
make a short clarification (like "you can't circumvent the property
modifier via
Reflection"), I'll do it.

Sorry for the lengthy response, but I really hope that I managed to clarify
the whys behind the proposal.

M=C3=A1t=C3=A9

--0000000000002bef8105a110d1e6--