Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109117
MIME-Version: 1.0
References: <CAH5C8xVY5SFLBt2jZ9dx93rQC_Xjp4pKZJ+MP=K1TbjyDi9CDA@mail.gmail.com>
 <CAAKU0unH_QcZppp4AHbx5ZhUFzGOmmt448nF2aC-qVPGWX_F0Q@mail.gmail.com>
In-Reply-To: <CAAKU0unH_QcZppp4AHbx5ZhUFzGOmmt448nF2aC-qVPGWX_F0Q@mail.gmail.com>
Date: Wed, 18 Mar 2020 03:34:35 +0100
Message-ID: <CAH5C8xXttiKzezK7QJ96ZHMAuaUKuJXaAbphvUWUk=kQvrZL0g@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004a2b5d05a117e567"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000004a2b5d05a117e567
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Levi,

Thank you very much for your feedback! I'll try to answer some of your
concerns.

Chiming in to express my disappointment that `final` wasn't a voting choice=
.
>

When I started to draft the RFC, I realized that a final property modifier
that I wanted
to propose would be pretty much inconsistent with final's current behaviour
(since it
currently controls inheritance), that's why we shouldn't copy from Java in
this case.
Now, readonly is the most popular choice in the vote - which directly comes
from C#.

  - It doesn't support default values, and doesn't defend that choice
> well in my opinion.
>

I wouldn't have thought before that this omission would be a double edged
sword.. :)
But I admit, I didn't really provide a well-expressed reasoning about the
choice
in the RFC. That was a fault. However, we talked about the decision quite a
lot
in the very end of the discussion thread so you might find some answers
there
if you are curious about more info.


>   - I think clone should be able to change the value. It's similar to
> a constructor, and in fact I'd call it a "copy constructor."
>

I agree, it would be perfect if clone worked smoothly. However, my
decision was to cut this aspect off from the current proposal since it's
not an
absolute prerequisite of "write-once" properties in my opinion. Plus,
I wanted to avoid the situation when the RFC grows so big that we miss fine=
r
details out from the discussion, or when the whole feature gets rejected
because a smaller detail has the wrong syntax/behaviour... Now, it seems
that the whole feature can get rejected because some (IMO less important)
decisions were postponed. That's Catch-22?

Just one more note about this topic: clone + final doesn't work well
together even
in Java (
https://en.wikipedia.org/wiki/Clone_(Java_method)#clone()_and_final_fields)=
,
so it's not a kind of a problem that other languages could easily overcome.
In turn,
I would absolutely like to offer a more ergonomic solution for PHP as soon
as possible.
Please, have a look at my previous response to Nicolas where I showed the
two alternatives that already came up. :) Any comments are welcome!


>   - The property type is mandatory. I am less certain about this, but
> do not like it.
>

Yes, I see your point. Because of the limitations of the current type
system,
we had to choose: we either leave untyped properties out of the game, or
start to treat them as if they had the mixed type (so a readonly $foo
 property
would be equivalent to readonly mixed $foo). It's just the smaller problem
with the latter solution that the mixed type only has a draft RFC (where
the debate
was mainly about if it should contain void or null...), but in my opinion,
the implicit
type conversion would be a mistake. This modifier shouldn't change
the initialization rules of the property. At least this is what I think
now, and
that's why we rather chose the tradeoff to eliminate untyped properties.


> I do appreciate the RFC, but think it needs a bit more work.
>

I also agree that my proposal couldn't give a definitive answer to all the
possible
questions that came up. But we - those ones who took part in the discussion
-
basically agreed that the feature is useful in spite of these unknowns.
That's
why we decided that the proposal should only keep the most important things=
,
and carve off the rest - what's controversial or unknown yet (e.g. default
values
or "fixing" cloning).

The most advantageous consequence of being this conservative is that we
have more
time (thus we can get more feedback/freedom) until we fill in the missing
holes of the
feature. So we made the responsible choice by postponing not
clear/controversial
decisions (e.g. how to treat non-typed properties) instead of trying to
immediately
guess the use-cases or to find workarounds. Since it's much-much easier to
add support for a new thing than to revert existing rules, I believe we
made a
good decision. I think something similar happened when the parameter type
system
was extended with scalar, then nullable, and finally with the void type, or
when
parameter covariance initially only supported omitting the type and 2
releases later
your RFC made covariance and contravariance much more complete.

I hope I could give explanations to you why the RFC became what it is now,
and what our thought process was.

Cheers:
M=C3=A1t=C3=A9

--0000000000004a2b5d05a117e567--