Readonly properties - immutability by default

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:

     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:

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

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:

     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:

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.

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:

    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:

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.

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.

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

I don't think the way it is going to be realeased is elegant solution

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.

--

To unsubscribe, visit: https://www.php.net/unsub.php

@Nikita Popov nikita.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:

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.

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

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

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

To unsubscribe, visit: https://www.php.net/unsub.php