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).


On Fri, Jul 16, 2021 at 10:06 AM Nikita Popov <nikita....@gmail.com> wrote:

> On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk <zsidel...@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
>

Reply via email to