Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115436
To: internals@lists.php.net
References: <CAM0CcxjJYYRrdzNjm285OQ6zDS8J7tqi0kLBeTGAP-2JXyqrDw@mail.gmail.com>
 <CAF+90c_P6z3ayqYRf09+L8zXUz-BizSX4A8oB=k2dwyJRn6EuA@mail.gmail.com>
 <CAM0CcxiHUEitc+EKor_7LXzhBTRkOG=Ef075Povzyu1ZnwhavA@mail.gmail.com>
Message-ID: <d137ab52-3f0d-1ed2-77ba-d5137ebd3820@allenjb.me.uk>
Date: Fri, 16 Jul 2021 11:04:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <CAM0CcxiHUEitc+EKor_7LXzhBTRkOG=Ef075Povzyu1ZnwhavA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Readonly properties - immutability by default
From: php.lists@allenjb.me.uk (AllenJB)


On 16/07/2021 09:11, Eugene Sidelnyk 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;
> ```
>
> 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).

I do not like this suggestion because it's too subtle / non-obvious. 
Think from the point of view of an inexperienced developer who is 
reading through code and they come across this. What does it mean? 
What's different about it? They might not even notice the subtle 
different to other parameters, then get frustrated when the changes 
they've made don't work and they have to waste time going back to redo them.

The readonly keyword in front of properties is clear. Without even 
reading the manual a new developer coming across this for the first time 
will have some idea of how they can expect it to work / how it should be 
used.

I think that your "future scope" of readonly variables using the same no 
$ format likely has problems with constants and keywords. This would 
cause more problems when new keywords are added to the language. Even if 
the language itself doesn't have problems, I think it could 
significantly affect the readability of code in many cases.

I think that a better suggestion would be to offer 'ro' as an 
(additional) alternative to 'readonly'. It's still shorter and I think 
that its meaning is likely to be understood / guessable by a significant 
proportion of (even inexperienced) developers.