Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115437
MIME-Version: 1.0
References: <CAM0CcxjJYYRrdzNjm285OQ6zDS8J7tqi0kLBeTGAP-2JXyqrDw@mail.gmail.com>
 <CAF+90c_P6z3ayqYRf09+L8zXUz-BizSX4A8oB=k2dwyJRn6EuA@mail.gmail.com> <CAM0CcxiHUEitc+EKor_7LXzhBTRkOG=Ef075Povzyu1ZnwhavA@mail.gmail.com>
In-Reply-To: <CAM0CcxiHUEitc+EKor_7LXzhBTRkOG=Ef075Povzyu1ZnwhavA@mail.gmail.com>
Date: Fri, 16 Jul 2021 12:10:56 +0200
Message-ID: <CAF+90c-iT=RFkxBC=0=MckotRXu0ddxnExa-Q=0F8qGdHGan0Q@mail.gmail.com>
To: Eugene Sidelnyk <zsidelnik@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009f614005c73ace3b"
Subject: Re: [PHP-DEV] Readonly properties - immutability by default
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000009f614005c73ace3b
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 16, 2021 at 10:11 AM Eugene Sidelnyk <zsidelnik@gmail.com>
wrote:

> Thanks for your response!
> Anyway, I probably put it wrong by saying "by default", so let me clarify
> myself.
>
> What I really mean is omitting the dollar sign. So everything remains the
> same with ordinary properties (which are mutable), and we introduce
> immutable (readonly) properties as another type of them.
> It looks like a great default:
> ```php
>     public string name;
> ```
>

Ah, I see. I didn't get that the missing dollar sign is a relevant part of
the example, I thought it was just a typo.

I can't say I like this proposal, because it's very subtle. "public string
$name" is a mutable property, "public string name" is immutable. I can kind
of see where you're coming from here, given how generally "foo" in PHP
refers to immutable symbols like constants, functions or classes, while
"$foo" refers to a mutable symbol. But that's something that applies to use
of the symbol. We're always explicit at the declaration site, it's const
FOO, function foo, class Foo etc. Here mutability is decided by single $
character in the declaration, which doesn't have a particular obvious
connection to mutability.

Regards,
Nikita


> So, once again, it has nothing to do with backward compatibility. No one
> disposes the way properties are currently working. We introduce a new
> _type_ or _kind_ of properties - readonly.
>
> Also I see useful future scope like readonly parameters:
>
> ```php
> function foo(int firstParam, bool secondParam)
> {
>   // no way to modify it, Error
>   firstParam = 23 * secondParam;
>
>   return firstParam * secondParam;
> }
> ```
>
> Yes, we can implement this with another keyword (again, `readonly`), but
> as I see, only few people will use it because it is too complicated
> (really, instead of simply declaring an argument, a programmer has to write
> a bunch of other stuff in front of it for every single method and
> function).
>
>
> On Fri, Jul 16, 2021 at 10:06 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk <zsidelnik@gmail.com>
>> wrote:
>>
>>> This is replica of github PR comments:
>>>
>>> Hi there!
>>> Isn't it better to simplify this a bit? I mean `readonly` keyword is
>>> really
>>> long to type every time we need such property. Earlier (in php7.3)
>>> properties were defined only with visibility modifier. Now it is going to
>>> become *toooo verbose*.
>>>
>>> ```php
>>> class A
>>> {
>>>     // 24 characters before actual property name
>>>     readonly public string $name;
>>>     readonly public string $another;
>>>
>>>     public function __construct(string $var)
>>>     {
>>>         $this->name = $var;
>>>         $this->another = $var;
>>>     }
>>> }
>>>
>>> $a = new A('foo');
>>> var_dump($a);
>>> ```
>>>
>>> What seems for me to be better is remove `readonly` modifier at all, with
>>> somewhat different modification. Look at the code below. This is intended
>>> to work the same way as previous example.
>>>
>>> ```php
>>> class A
>>> {
>>>     // 14 characters before actual property name
>>>     public string name;
>>>     public string another;
>>>
>>>     public function __construct(string $var)
>>>     {
>>>         $this->name = $var;
>>>         $this->another = $var;
>>>     }
>>> }
>>>
>>> $a = new A('foo');
>>> var_dump($a);
>>> ```
>>>
>>> This is less explicit (we don't actually write `readonly` keyword), and
>>> it
>>> may be confusing for some programmer who is new to php. However after
>>> first
>>> attempt of modification, such layman will understand it's syntax and keep
>>> with it.
>>>
>>> Readonly properties are really useful for DDD, where everything is going
>>> to
>>> be immutable. It promotes best practices. However for people to use it,
>>> syntax should be concise and brief.
>>>
>>> @nikic , want to hear your thoughts on this.
>>>
>>> * kolardavid <https://github.com/kolardavid> * 1 hour ago
>>> <https://github.com/php/php-src/pull/7089#issuecomment-881191365>
>>>
>>> @rela589n <https://github.com/rela589n> First of all, you are coming
>>> late
>>> (as me before), since this RFC is already voted and implemented
>>> completely.
>>> Anyway, I find your suggestion bad. The truth is, that it is a bit more
>>> verbose, but I am OK with that. It might be annoying to write (word
>>> protected is even longer) but it is far better to read. It makes the code
>>> more clear. Human brain is very well "optimized" to notice words it is
>>> used
>>> to, more than symbols. This idea stays behind the fact that Delphi for
>>> example uses begin/end instead of { and } (even though I am kind of tired
>>> of it as well). Anyway, your solution of dropping $ for readonly property
>>> would be nightmare for everyone, not just beginners. I am sure that
>>> @nikic
>>> <https://github.com/nikic> will say the same, since he seems as
>>> pedantic as
>>> I am about these things. Since all modifiers are already nice
>>> self-explaining word, there is no point in doing this differently for new
>>> modifier. It wouldn't be consistent, nor convenient. Mixed properties
>>> with
>>> and without $ sign would look like typo, not intention.
>>>
>>> * rela589n <https://github.com/rela589n> * 26 minutes ago
>>> <https://github.com/php/php-src/pull/7089#issuecomment-881206048>
>>> The philosophy of the Functional Programming <
>>> http://en.wikipedia.org/wiki/Functional_programming> paradigm is
>>> strongly
>>> geared towards all "variables" being immutable, and "mutable" ones being
>>> only allowed in extreme cases (ie, for I/O. This will not look like a
>>> typo.
>>> Immutability should be provided by default. BTW, in future scope we can
>>> create "readonly" variables. So that once a variable is defined, no one
>>> can
>>> change its value. I oppose creating kind of `let` and `const` for this.
>>>
>>> * rela589n <https://github.com/rela589n> * 21 minutes ago
>>> <https://github.com/php/php-src/pull/7089#issuecomment-881208237>
>>> > Anyway, your solution of dropping $ for readonly property would be
>>> nightmare for everyone, not just beginners
>>>
>>> It would be a nightmare if these values could be changed. As we can't
>>> rewrite `readonly` property, it looks like a constant. This concept of
>>> readonly properties should come along with constants not only by
>>> semantics,
>>> but also by syntax.
>>>
>>> * rela589n <https://github.com/rela589n> * 18 minutes ago
>>> <https://github.com/php/php-src/pull/7089#issuecomment-881209502>
>>> > The truth is, that it is a bit more verbose, but I am OK with that. It
>>> might be annoying to write (word protected is even longer) but it is far
>>> better to read.
>>>
>>> We already have Java with it's verbose syntax. We should think what
>>> should
>>> be default and safe behaviour covering most cases and make such verbose
>>> constructions for cases not covered by default logic.
>>>
>>
>> We cannot make properties readonly by default, because that would be a
>> major backwards compatibility break.
>>
>> If you're going for brevity, something you can do is omit the visibility
>> specifier, as it is public by default. "readonly int $prop" works.
>>
>> Regards,
>> Nikita
>>
>

--0000000000009f614005c73ace3b--