Readonly properties - immutability by default

  115430
July 16, 2021 06:45 zsidelnik@gmail.com (Eugene Sidelnyk)
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.
  115431
July 16, 2021 07:06 nikita.ppv@gmail.com (Nikita Popov)
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
  115432
July 16, 2021 08:11 zsidelnik@gmail.com (Eugene Sidelnyk)
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 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 >
  115434
July 16, 2021 10:02 pierre-php@processus.org (Pierre)
Le 16/07/2021 à 10:11, Eugene Sidelnyk a écrit :
> 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).
Hello, I'm very happy that the readonly properties RFC did pass, I waited for this for a long time. I like the "readonly" explicit keyword, explicit is always better than implicit for disambiguation and readability. I'd wish having per-default readonly properties as well, but this is PHP and fundamentals cannot be changed just like that, it's not Rust, or any other language, PHP is PHP. Explicit "readonly" is in my opinion the best option, it's easy to type, and it's easy to read, and it's the same keyword in many other languages. On the opposite side, omiting the $ sign seems like a huge mind-fuck, easy to miss-read, easy to miss-type, error prone and obscure. Regards, -- Pierre
  115436
July 16, 2021 10:04 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.
  115437
July 16, 2021 10:10 nikita.ppv@gmail.com (Nikita Popov)
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 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 >> >
  115452
July 17, 2021 11:47 a.leathley@gmx.net (Andreas Leathley)
On 16.07.21 09:06, Nikita Popov wrote:
> 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.
Would it be possible to adapt constructor property promotion to support this (as far as I tell, it currently does not)? Namely: class A {     public function __construct(         readonly int $id,     ) {     } } According to the constructor property promotion RFC, the promotion only happens when public, private and protected is used for an constructor parameter. With the readonly RFC accepted, it would make sense to also do constructor property promotion when readonly is used, to avoid the explicit public, because readonly would also clearly define the parameter as not-only-a-parameter.
  115454
July 17, 2021 14:57 zsidelnik@gmail.com (Eugene Sidelnyk)
I don't think the way it is going to be realeased is elegant solution

On Sat, Jul 17, 2021, 2:47 PM Andreas Leathley leathley@gmx.net> wrote:

> On 16.07.21 09:06, Nikita Popov wrote: > > 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. > > Would it be possible to adapt constructor property promotion to support > this (as far as I tell, it currently does not)? Namely: > > class A { > public function __construct( > readonly int $id, > ) { > } > } > > According to the constructor property promotion RFC, the promotion only > happens when public, private and protected is used for an constructor > parameter. With the readonly RFC accepted, it would make sense to also > do constructor property promotion when readonly is used, to avoid the > explicit public, because readonly would also clearly define the > parameter as not-only-a-parameter. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115438
July 16, 2021 10:12 weirdan@gmail.com (Bruce Weirdan)
On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> wrote:

> 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.
If every property of the class is readonly it would probably be better to declare that with a class modifier. E.g. ```php readonly class Entity { public int $count; public string $data; } ``` Though `readonly` doesn't look like a perfect fit in that position to me. -- Best regards, Bruce Weirdan mailto:weirdan@gmail.com
  115439
July 16, 2021 11:48 zsidelnik@gmail.com (Eugene Sidelnyk)
@Nikita Popov ppv@gmail.com> I'm not sure what you mean by saying
this:

> We're always explicit at the declaration site, it's const FOO, function foo, class Foo etc
Regarding your message
> Here mutability is decided by single $ character in the declaration, which doesn't have a particular obvious connection to mutability.
Yes, that is not really obvious about property mutability when we look at the code. I think it is probably better to rephrase it into something like: New way of properties definition without dollar sign. Not only do we remove dollar sign, but these properties can not be reassigned. Looking from this perspective we are trying to improve code quality and developer experience. Using immutability (as well as type-hints with strict typing) makes code less error prone. This should be promoted in the PHP community. What I want to say is: good things should be easily done, easier than things which are more error prone. Again, about explicitness and obviousness. Imagine (just for a second) that all existing properties are immutable by default. Then someone submits RFC to add mutability for them. It is accepted to add a new keyword like this: ```php mutable public string $bar; ``` Hence I mean: currently we have one default option (mutable properties) from 2 options. Why do we need to create such a long keyword just to use readonly properties (if immutability is better than mutability)? Regards, Eugene On Fri, Jul 16, 2021 at 1:13 PM Bruce Weirdan <weirdan@gmail.com> wrote:
> On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> > wrote: > > > 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. > > If every property of the class is readonly it would probably be better > to declare that with a class modifier. > > E.g. > > ```php > readonly class Entity { > public int $count; > public string $data; > } > ``` > > Though `readonly` doesn't look like a perfect fit in that position to me. > > -- > Best regards, > Bruce Weirdan mailto: > weirdan@gmail.com >
  115442
July 16, 2021 16:13 larry@garfieldtech.com ("Larry Garfield")
On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote:
> @Nikita Popov ppv@gmail.com> I'm not sure what you mean by saying > this: > > > We're always explicit at the declaration site, it's const FOO, function > foo, class Foo etc > > > Regarding your message > > > Here mutability is decided by single $ character in the declaration, > which doesn't have a particular obvious connection to mutability. > > Yes, that is not really obvious about property mutability when we look at > the code. > I think it is probably better to rephrase it into something like: New way > of properties definition without dollar sign. Not only do we remove dollar > sign, but these properties can not be reassigned. > > Looking from this perspective we are trying to improve code quality and > developer experience. Using immutability (as well as type-hints with strict > typing) makes code less error prone. This should be promoted in the PHP > community. > What I want to say is: good things should be easily done, easier than > things which are more error prone. > > Again, about explicitness and obviousness. > Imagine (just for a second) that all existing properties are immutable by > default. Then someone submits RFC to add mutability for them. It is > accepted to add a new keyword like this: > > ```php > mutable public string $bar; > ``` > > Hence I mean: currently we have one default option (mutable properties) > from 2 options. Why do we need to create such a long keyword just to use > readonly properties (if immutability is better than mutability)? > > Regards, Eugene
A) Please don't top post. This is a bottom-post-centric list. B) As others have said, if we were designing the language today we would do it very differently. I'd likely push for following Rust's example of immutable by default, super strong typing, and a `mut` keyword to poke holes in the immutability where necessary. However, we have ample existing code that cannot be broken, so that limits what we can do. That means adding a readonly/immutable/whatever flag is the only real option, even if it is annoyingly verbose. I can see the logic behind "initialize at runtime constants" which is what you're describing, as an alternative. However, that breaks a ton of existing patterns. 1) Variables in PHP always begin with $. For all time, Always. 2) Objects do not have constants. Classes have constants. Introducing object-level constants is potentially confusing. 3) Constants shouldn't be set even once. Properties can be, but properties have $ on them. 3) What would reflection do with these object constants? Are they still properties according to reflection, or are they something else? Can I enumerate mutable properties and constant properties together or separately? This gets complicated fast. I agree with the point that the verbosity of `readonly` is potentially annoying, but we haven't seen it in practice yet. If it ends up being a problem, then as someone else suggested a more likely solution is a `readonly` flag on the class, possibly with a `mut` keyword on the property to opt it back out, or something like that. Not ideal, but probably the best we could do. Having very subtly different syntax for a very significant behavioral difference in properties seems like a landmine waiting to happen that would only confuse people. --Larry Garfield
  115448
July 17, 2021 06:39 zsidelnik@gmail.com (Eugene Sidelnyk)
> Please don't top post. This is a bottom-post-centric list.
Can you please tell me what mailing client you use and what should I?
> if we were designing the language today we would do it very differently.
This reminds me working with legacy code in the team which says to write the code in the style in which the project is written. You are trying to make your code more maintainable and readable, decompose your functionality, define clear pre and post conditions. Then comes time for code review and teamlead orders you to throw everything away and write the same legacy as they do because project is written this way. PS. No more do I work in this team. Can you please explain what prevents us from doing the best (like if we were designing the language today) for new features now? 1) Dollars in PHP
> Variables in PHP always begin with $. For all time, Always.
Yes, but let's not confuse variables (which by definition can be rewritten) with values that can get it's value only once. Almost every time we encounter $ sign in PHP, we can change it's value either as a $property or $variable. All the time we encounter "immutable descriptor for value" (fancy name for not-variable) without dollar sign, it can't be changed. I am talking about constants. 2) Object constants
> Objects do not have constants. Classes have constants.
Yes, objects do not have constants, but may have `readonly` properties which use constant-like syntax because they can't be ever changed. I don't understand why you name it constants if it is not.
> Introducing object-level constants is potentially confusing.
Yes, introducing constants may be confusing. Introduction of `readonly` properties with dollarless syntax is very logical. 3) Constants and Properties
> Constants shouldn't be set even once. Properties can be, but properties have $ on them.
Again, dollar sign is used for mutable value descriptors. Constants don't have dollar sign and are not overwritable. Readonly properties should not have dollar sign because they are not overwritable as well. 4) Reflection part doesn't seem to be complicated here
> Are they still properties according to reflection, or are they something else?
According to reflection, these are properties.
> What would reflection do with these object constants?
The reflection part should remain the same as it is with current RFC so that `ReflectionProperty::isReadOnly` is added as well as `IS_READONLY` flag added to the modifiers list.
> Can I enumerate mutable properties and constant properties together or separately?
Why would you need to enumerate them separately? All of them are properties by definition.
> Having very subtly different syntax for a very significant behavioral difference in properties seems like a landmine waiting to happen that would
only confuse people. We are in the programming world. In PHP if someone gets undermined, he will know what he did wrong right in a few seconds. After blowing up (if this will ever happen), programmer will write the code with understanding how and why it works this way. On Fri, Jul 16, 2021 at 7:14 PM Larry Garfield <larry@garfieldtech.com> wrote:
> On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote: > > @Nikita Popov ppv@gmail.com> I'm not sure what you mean by > saying > > this: > > > > > We're always explicit at the declaration site, it's const FOO, function > > foo, class Foo etc > > > > > > Regarding your message > > > > > Here mutability is decided by single $ character in the declaration, > > which doesn't have a particular obvious connection to mutability. > > > > Yes, that is not really obvious about property mutability when we look at > > the code. > > I think it is probably better to rephrase it into something like: New way > > of properties definition without dollar sign. Not only do we remove > dollar > > sign, but these properties can not be reassigned. > > > > Looking from this perspective we are trying to improve code quality and > > developer experience. Using immutability (as well as type-hints with > strict > > typing) makes code less error prone. This should be promoted in the PHP > > community. > > What I want to say is: good things should be easily done, easier than > > things which are more error prone. > > > > Again, about explicitness and obviousness. > > Imagine (just for a second) that all existing properties are immutable by > > default. Then someone submits RFC to add mutability for them. It is > > accepted to add a new keyword like this: > > > > ```php > > mutable public string $bar; > > ``` > > > > Hence I mean: currently we have one default option (mutable properties) > > from 2 options. Why do we need to create such a long keyword just to use > > readonly properties (if immutability is better than mutability)? > > > > Regards, Eugene > > A) Please don't top post. This is a bottom-post-centric list. > > B) As others have said, if we were designing the language today we would > do it very differently. I'd likely push for following Rust's example of > immutable by default, super strong typing, and a `mut` keyword to poke > holes in the immutability where necessary. > > However, we have ample existing code that cannot be broken, so that limits > what we can do. That means adding a readonly/immutable/whatever flag is > the only real option, even if it is annoyingly verbose. > > I can see the logic behind "initialize at runtime constants" which is what > you're describing, as an alternative. However, that breaks a ton of > existing patterns. > > 1) Variables in PHP always begin with $. For all time, Always. > > 2) Objects do not have constants. Classes have constants. Introducing > object-level constants is potentially confusing. > > 3) Constants shouldn't be set even once. Properties can be, but > properties have $ on them. > > 3) What would reflection do with these object constants? Are they still > properties according to reflection, or are they something else? Can I > enumerate mutable properties and constant properties together or > separately? This gets complicated fast. > > I agree with the point that the verbosity of `readonly` is potentially > annoying, but we haven't seen it in practice yet. If it ends up being a > problem, then as someone else suggested a more likely solution is a > `readonly` flag on the class, possibly with a `mut` keyword on the property > to opt it back out, or something like that. Not ideal, but probably the > best we could do. > > Having very subtly different syntax for a very significant behavioral > difference in properties seems like a landmine waiting to happen that would > only confuse people. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115445
July 16, 2021 21:09 mike@newclarity.net (Mike Schinkel)
> On Jul 16, 2021, at 6:12 AM, Bruce Weirdan <weirdan@gmail.com> wrote: > > On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> wrote: > >> 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. > > If every property of the class is readonly it would probably be better > to declare that with a class modifier. > > E.g. > > ```php > readonly class Entity { > public int $count; > public string $data; > } > ```
Having a "readonly" class where the properties are read-only by default makes sense to me, but maybe the better way to do it is with an attribute? #[Readonly] class Entity { public int $count; public string $data; } OTOH, that would be inconsistent with using `readonly` as a keyword for properties. -Mike P.S. Maybe readonly properties should be implemented with an attribute instead of a keyword? But then that would be opening a can of worms...
  115447
July 17, 2021 05:40 zsidelnik@gmail.com (Eugene Sidelnyk)
> Having a "readonly" class where the properties are read-only by default makes sense to me, but maybe the better way to do it is with an attribute?
We already have such an attribute provided. It is called [`#[Immutable]`]( https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable ). If the intention is to add some logic for attributes, then unlikely it is going to be accepted because attributes by definition are meta-data. It doesn't add any logic for program. On Sat, Jul 17, 2021 at 12:09 AM Mike Schinkel <mike@newclarity.net> wrote:
> > On Jul 16, 2021, at 6:12 AM, Bruce Weirdan <weirdan@gmail.com> wrote: > > > > On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk <zsidelnik@gmail.com> > wrote: > > > >> 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. > > > > If every property of the class is readonly it would probably be better > > to declare that with a class modifier. > > > > E.g. > > > > ```php > > readonly class Entity { > > public int $count; > > public string $data; > > } > > ``` > > Having a "readonly" class where the properties are read-only by default > makes sense to me, but maybe the better way to do it is with an attribute? > > #[Readonly] > class Entity { > public int $count; > public string $data; > } > > OTOH, that would be inconsistent with using `readonly` as a keyword for > properties. > > -Mike > P.S. Maybe readonly properties should be implemented with an attribute > instead of a keyword? But then that would be opening a can of worms... > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115450
July 17, 2021 09:04 mike@newclarity.net (Mike Schinkel)
> On Jul 17, 2021, at 1:40 AM, Eugene Sidelnyk <zsidelnik@gmail.com> wrote: > > > Having a "readonly" class where the properties are read-only by default makes sense to me, but maybe the better way to do it is with an attribute? > > We already have such an attribute provided. It is called [`#[Immutable]`](https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable <https://blog.jetbrains.com/phpstorm/2020/10/phpstorm-2020-3-eap-4/#immutable>).
Actually, you are confusing PhpStorm's inclusion of PhpStorm-specific userland attributes where the PhpStorm team are probably trying to drive defacto-standard meanings for those attributes they documents with attributes that has specific meanings and behavior recognized by PHP itself. Nothing against PhpStorm — it is my IDE/editor of choice and I applaud JetBrain's leadership in this area — but their attributes are still just their attributes, not attributes defined by in a PHP RFC.
> If the intention is to add some logic for attributes, then unlikely it is going to be accepted because attributes by definition are meta-data. It doesn't add any logic for program.
Actually, that is not true either. PHP already has one attribute that PHP itself recognizes, named "Attribute." As Larry Garfield wrote[1]: "The #[Attribute] attribute tells PHP “yes, this class can be loaded as an attribute.” You can also see that future scope was explicitly envisioned[2] that some small number of attributes might potentially be more than just metadata. -Mike [1] https://platform.sh/blog/2020/php-8-0-feature-focus-attributes/ <https://platform.sh/blog/2020/php-8-0-feature-focus-attributes/> [2] https://wiki.php.net/rfc/attributes_v2#future_scope <https://wiki.php.net/rfc/attributes_v2#future_scope>