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.
