Re: [PHP-DEV] readonly properties

[Guilliam Xavier]

>
> >> 2. DateInterval->days
> >>
> >> $interval = (new DateTime())->diff(new DateTime());
> >> var_dump($interval->days); // 0
> >> $refl = (new ReflectionObject($interval))->getProperty('days');
> >> var_dump($refl->isReadOnly()); // false
> >> var_dump($refl->isPublic()); // true
> >> $interval->days = 2;
> >> var_dump($interval->days);  // 0
> >>
> > The DateInterval properties are currently implemented as getters/setters
> on
> > some internal state. Some of those are getter-only, but probably not
> fully
> > immutable.
>
> I was referring to the property "days" only as this is a non writable
> value generated on "DateTime->diff".
>
> As you can see in the snipped it doesn't allow to modify days but it
> also doesn't fail which seems wrong to me.
>
> I don't have much knowledge about internals but would it be possible to
> define "public readonly int|false $days" not using getters/setters and
> keep all other properties as it?
>

Hi,

FWIW, I too agree that [$interval->days, $interval->days = 2,
$interval->days] giving [0, 2, 0] without any warning (or
https://3v4l.org/h8Cju for a variation) seems wrong.

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] readonly properties

[Marc]

On 8/13/21 4:56 PM, Nikita Popov wrote:

On Thu, Aug 12, 2021 at 9:16 PM Marc  wrote:


Hi,

As 8.1 adds readonly properties I wonder which build-in properties
should be defined readonly.

Currently I could find build-in readonly properties only on PDO and DOM.


Very incomplete list where readonly properties could make sense:

1. Enum properties:

enum Test:string {
  case TEST = 'test';
}

$case = TEST::TEST;
$refl = (new ReflectionObject($case))->getProperty('value');
var_dump($refl->isReadOnly());  // false
var_dump($refl->isPublic());  // true
$case->value = 'foo'; // Fatal error: Uncaught Error: Enum properties
are immutable


Yeah, these are a perfect use case for "readonly". Done in
https://github.com/php/php-src/commit/caefc6a50789295b0993c4e657c825484650172a.
This actually fixes a bug, because the homegrown "readonly" implementation
for enums was not quite correct.


WOW this was fast. Less code and even a bugfix +1




2. DateInterval->days

$interval = (new DateTime())->diff(new DateTime());
var_dump($interval->days); // 0
$refl = (new ReflectionObject($interval))->getProperty('days');
var_dump($refl->isReadOnly()); // false
var_dump($refl->isPublic()); // true
$interval->days = 2;
var_dump($interval->days);  // 0


The DateInterval properties are currently implemented as getters/setters on
some internal state. Some of those are getter-only, but probably not fully
immutable.


I was referring to the property "days" only as this is a non writable 
value generated on "DateTime->diff".


As you can see in the snipped it doesn't allow to modify days but it 
also doesn't fail which seems wrong to me.


I don't have much knowledge about internals but would it be possible to 
define "public readonly int|false $days" not using getters/setters and 
keep all other properties as it?





3. Exception properties

Exception properties are protected but does it really make sense to be
able to modify an exception property after initialization?

I know this would be a BC break :(


There is definitely code out there relying on modifying both protected and
private Exception properties, I don't think we want to touch these without
cause.


Yea you are probably right - it would be a heavy BC break for not much 
profit.



Regards,
Nikita



Thank you very much Nikita!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] readonly properties

[Nikita Popov]

On Thu, Aug 12, 2021 at 9:16 PM Marc  wrote:

> Hi,
>
> As 8.1 adds readonly properties I wonder which build-in properties
> should be defined readonly.
>
> Currently I could find build-in readonly properties only on PDO and DOM.
>
>
> Very incomplete list where readonly properties could make sense:
>
> 1. Enum properties:
>
> enum Test:string {
>  case TEST = 'test';
> }
>
> $case = TEST::TEST;
> $refl = (new ReflectionObject($case))->getProperty('value');
> var_dump($refl->isReadOnly());  // false
> var_dump($refl->isPublic());  // true
> $case->value = 'foo'; // Fatal error: Uncaught Error: Enum properties
> are immutable
>

Yeah, these are a perfect use case for "readonly". Done in
https://github.com/php/php-src/commit/caefc6a50789295b0993c4e657c825484650172a.
This actually fixes a bug, because the homegrown "readonly" implementation
for enums was not quite correct.


> 2. DateInterval->days
>
> $interval = (new DateTime())->diff(new DateTime());
> var_dump($interval->days); // 0
> $refl = (new ReflectionObject($interval))->getProperty('days');
> var_dump($refl->isReadOnly()); // false
> var_dump($refl->isPublic()); // true
> $interval->days = 2;
> var_dump($interval->days);  // 0
>

The DateInterval properties are currently implemented as getters/setters on
some internal state. Some of those are getter-only, but probably not fully
immutable.

3. Exception properties
>
> Exception properties are protected but does it really make sense to be
> able to modify an exception property after initialization?
>
> I know this would be a BC break :(
>

There is definitely code out there relying on modifying both protected and
private Exception properties, I don't think we want to touch these without
cause.

Regards,
Nikita

[PHP-DEV] readonly properties

[Marc]

Hi,

As 8.1 adds readonly properties I wonder which build-in properties 
should be defined readonly.


Currently I could find build-in readonly properties only on PDO and DOM.


Very incomplete list where readonly properties could make sense:

1. Enum properties:

enum Test:string {
    case TEST = 'test';
}

$case = TEST::TEST;
$refl = (new ReflectionObject($case))->getProperty('value');
var_dump($refl->isReadOnly());  // false
var_dump($refl->isPublic());  // true
$case->value = 'foo'; // Fatal error: Uncaught Error: Enum properties 
are immutable



2. DateInterval->days

$interval = (new DateTime())->diff(new DateTime());
var_dump($interval->days); // 0
$refl = (new ReflectionObject($interval))->getProperty('days');
var_dump($refl->isReadOnly()); // false
var_dump($refl->isPublic()); // true
$interval->days = 2;
var_dump($interval->days);  // 0


3. Exception properties

Exception properties are protected but does it really make sense to be 
able to modify an exception property after initialization?


I know this would be a BC break :(


Thanks for all the excellent work - Can't wait for 8.1 :)

Marc

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties - immutability by default

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

Re: [PHP-DEV] Readonly properties - immutability by default

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties - immutability by default

[Mike Schinkel]

> On Jul 17, 2021, at 1:40 AM, Eugene Sidelnyk  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
>  
> ).

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/ 

[2] https://wiki.php.net/rfc/attributes_v2#future_scope 
 

Re: [PHP-DEV] Readonly properties - immutability by default

[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 
wrote:

> On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote:
> > @Nikita Popov  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 

Re: [PHP-DEV] Readonly properties - immutability by default

[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  wrote:

> > On Jul 16, 2021, at 6:12 AM, Bruce Weirdan  wrote:
> >
> > On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk 
> 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
>
>

Re: [PHP-DEV] Readonly properties - immutability by default

[Mike Schinkel]

> On Jul 16, 2021, at 6:12 AM, Bruce Weirdan  wrote:
> 
> On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk  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

Re: [PHP-DEV] Readonly properties - immutability by default

[Larry Garfield]

On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote:
> @Nikita Popov  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

Re: [PHP-DEV] Readonly properties - immutability by default

[Eugene Sidelnyk]

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

> On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk 
> 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:
> weir...@gmail.com
>

Re: [PHP-DEV] Readonly properties - immutability by default

[Bruce Weirdan]

On Fri, Jul 16, 2021 at 9:45 AM Eugene Sidelnyk  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:weir...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties - immutability by default

[Nikita Popov]

On Fri, Jul 16, 2021 at 10:11 AM 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;
> ```
>

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 
> wrote:
>
>> On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk 
>> 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 *t 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  * 1 hour ago
>>> 
>>>
>>> @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
>>>  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
>>> 

Re: [PHP-DEV] Readonly properties - immutability by default

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties - immutability by default

[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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties - immutability by default

[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  wrote:

> On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk 
> 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 *t 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  * 1 hour ago
>> 
>>
>> @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
>>  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  * 26 minutes ago
>> 
>> 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  * 21 minutes ago
>> 
>> > Anyway, your solution of dropping $ for readonly 

Re: [PHP-DEV] Readonly properties - immutability by default

[Nikita Popov]

On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk  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 *t 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  * 1 hour ago
> 
>
> @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
>  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  * 26 minutes ago
> 
> 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  * 21 minutes ago
> 
> > 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  * 18 minutes ago
> 
> > 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

[PHP-DEV] Readonly properties - immutability by default

[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 *t 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  * 1 hour ago


@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
 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  * 26 minutes ago

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  * 21 minutes ago

> 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  * 18 minutes ago

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

Re: [PHP-DEV] Readonly properties and interfaces

[Larry Garfield]

On Wed, Jul 7, 2021, at 10:33 PM, Brent Roose wrote:

> > The property accessor RFC (which didn't get to a vote) discussed this, and 
> > specifically proposed making properties part of the interface for... 
> > basically all the reasons given here.
> > 
> 
> I thought the RFC didn't go to vote because Nikita didn't feel like it 
> warranted the complexity:
> 
> > This RFC overlaps with the Property Accessors RFC. In particular, it 
> > implements the “only implicit get” aspect, though not with the exact same 
> > semantics. As mentioned in the RFC, I'm not convinced that the full 
> > complexity of accessors is truly warranted. Supporting readonly properties 
> > and asymmetric visibility would cover a significant portion of the 
> > use-cases, at a lower language complexity cost. [1]
> 
> Is there any reason to assume property accessors will be reconsidered for 
> 8.2? 

Nothing is guaranteed. :-)  However, Nikita said very clearly in the readonly 
discussion that he doesn't see it as precluding the asymmetric visibility 
portion of accessors, which is still simpler than full on explicit accessor 
methods.  We "just" have to convince Nikita that upgrading readonly to 
asymmetric visibility in 8.2 (with or without explicit methods) is justified, 
and that it should include the interface portion of that, too.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties and interfaces

[Pierre]

Le 07/07/2021 à 23:16, Larry Garfield a écrit :

The property accessor RFC (which didn't get to a vote) discussed this, and 
specifically proposed making properties part of the interface for... basically 
all the reasons given here.

My preference would be to add property accessors in 8.2 (at least the asymmetric 
visibility part), and then redefine `readonly` properties as a shorthand for a "get 
only" implicit accessor property; which, if I recall correctly, is essentially the 
same semantics as `readonly`.  (I didn't check the RFC; I'm going by memory here.)  That 
would include interface properties by nature.

--Larry Garfield


Using property accessors on interfaces is fine too, but the one thing 
that properties directly being defined on interfaces do bring is that 
you don't have to repeat implementation of those in your 
implementations. That's a detail, but a practical one.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Readonly properties and interfaces

[Brent Roose]

> On 7 Jul 2021, at 23:16, Larry Garfield  wrote:
> 
> On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
>> Hi internals
>> 
>> With the readonly properties RFC almost certainly accepted, I'd like to 
>> discuss an idea that's slightly related to them.
>> 
>> One of the problems that readonly properties solve is that they reduce 
>> the overhead of writing getters and setters. This is especially 
>> noticeable in objects that hold lots of data — data transfer objects, 
>> value objects, entities. And while public readonly properties will be a 
>> style of programming that not everyone likes, it's clear from the vote 
>> on the readonly RFC, as well as the community feedback, that it's a 
>> feature wanted by many.
>> 
>> That brings me to interfaces: currently we're only allowed to define 
>> methods on interfaces; historically this makes sense, since interfaces 
>> are meant to define behaviour, and not the implementation. Most OO 
>> language define behaviour using methods, and state using properties, 
>> which in turn are used to define the implementation.
>> 
>> But now, readonly properties are added.
>> 
>> Suddenly, class properties aren't just used for state anymore, they are 
>> also used to expose that state in an immutable way to the outside, 
>> where we'd use public getters (behaviour) and private properties 
>> (state) in the past, we can now combine them as public readonly 
>> properties. Wouldn't that imply that there are at least some cases 
>> where interface properties could also make sense?
>> 
>> A simple example:
>> 
>> Imagine we've got 10 different classes that share some behaviour: they 
>> are identifiable by a UUID. Next, imagine we've got a function that can 
>> specifically work with all classes that have a UUID. Proper OO teaches 
>> us to write an interface for this behaviour `Identifiable` or `HasUuid` 
>> or something alike. This interface would probably require its 
>> implementers to expose a `getUuid(): string` method. 
>> 
>> Without interfaces being able to define properties, we'll now have to 
>> implement a `getUuid()` method on all our 10 classes, nullifying the 
>> advantage we got from using `public readonly string $uuid` in the first 
>> place. If, on the other hand, this functionality was supported, we 
>> could write our interface like so, and wouldn't have to worry about any 
>> more boilerplate code:
>> 
>> ```
>> interface HasUuid
>> {
>>public readonly string $uuid;
>> }
>> ```
>> 
>> With the addition of readonly properties, now seems like a good time to 
>> discuss changing these rules. I realise these questions touch the core 
>> ideas of OO, so I reckon some people might have another opinion and I'd 
>> like to hear your thoughts.
>> 
>> To give you some more reading material, there is a precedent for 
>> interface properties in other languages:
>> 
>> - TypeScript supports them [1]
>> - C# supports them, albeit using property accessors [2]
>> - Swift supports them via Protocols [3]
>> 
>> Looking forward to hearing your thoughts.
>> 
>> Kind regards
>> Brent
>> 
>> [1] 
>> https://www.typescriptlang.org/docs/handbook/type-compatibility.html 
>> > > 
>> [2] 
>> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
>>  
>> 
>>  
>> >  
>> >
>>  
>> [3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 
>>  
>> > > 
> 
> The property accessor RFC (which didn't get to a vote) discussed this, and 
> specifically proposed making properties part of the interface for... 
> basically all the reasons given here.
> 

I thought the RFC didn't go to vote because Nikita didn't feel like it 
warranted the complexity:

> This RFC overlaps with the Property Accessors RFC. In particular, it 
> implements the “only implicit get” aspect, though not with the exact same 
> semantics. As mentioned in the RFC, I'm not convinced that the full 
> complexity of accessors is truly warranted. Supporting readonly properties 
> and asymmetric visibility would cover a significant portion of the use-cases, 
> at a lower language complexity cost. [1]

Is there any reason to assume property accessors will be reconsidered for 8.2? 

[1] https://wiki.php.net/rfc/readonly_properties_v2#rationale

Kind regards
Brent


> My preference would be to add property accessors in 

Re: [PHP-DEV] Readonly properties and interfaces

[Larry Garfield]

On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
> Hi internals
> 
> With the readonly properties RFC almost certainly accepted, I'd like to 
> discuss an idea that's slightly related to them.
> 
> One of the problems that readonly properties solve is that they reduce 
> the overhead of writing getters and setters. This is especially 
> noticeable in objects that hold lots of data — data transfer objects, 
> value objects, entities. And while public readonly properties will be a 
> style of programming that not everyone likes, it's clear from the vote 
> on the readonly RFC, as well as the community feedback, that it's a 
> feature wanted by many.
> 
> That brings me to interfaces: currently we're only allowed to define 
> methods on interfaces; historically this makes sense, since interfaces 
> are meant to define behaviour, and not the implementation. Most OO 
> language define behaviour using methods, and state using properties, 
> which in turn are used to define the implementation.
> 
> But now, readonly properties are added.
> 
> Suddenly, class properties aren't just used for state anymore, they are 
> also used to expose that state in an immutable way to the outside, 
> where we'd use public getters (behaviour) and private properties 
> (state) in the past, we can now combine them as public readonly 
> properties. Wouldn't that imply that there are at least some cases 
> where interface properties could also make sense?
> 
> A simple example:
> 
> Imagine we've got 10 different classes that share some behaviour: they 
> are identifiable by a UUID. Next, imagine we've got a function that can 
> specifically work with all classes that have a UUID. Proper OO teaches 
> us to write an interface for this behaviour `Identifiable` or `HasUuid` 
> or something alike. This interface would probably require its 
> implementers to expose a `getUuid(): string` method. 
> 
> Without interfaces being able to define properties, we'll now have to 
> implement a `getUuid()` method on all our 10 classes, nullifying the 
> advantage we got from using `public readonly string $uuid` in the first 
> place. If, on the other hand, this functionality was supported, we 
> could write our interface like so, and wouldn't have to worry about any 
> more boilerplate code:
> 
> ```
> interface HasUuid
> {
> public readonly string $uuid;
> }
> ```
> 
> With the addition of readonly properties, now seems like a good time to 
> discuss changing these rules. I realise these questions touch the core 
> ideas of OO, so I reckon some people might have another opinion and I'd 
> like to hear your thoughts.
> 
> To give you some more reading material, there is a precedent for 
> interface properties in other languages:
> 
> - TypeScript supports them [1]
> - C# supports them, albeit using property accessors [2]
> - Swift supports them via Protocols [3]
> 
> Looking forward to hearing your thoughts.
> 
> Kind regards
> Brent
> 
> [1] 
> https://www.typescriptlang.org/docs/handbook/type-compatibility.html 
>  
> [2] 
> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
>  
> 
>  
> [3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 
>  

The property accessor RFC (which didn't get to a vote) discussed this, and 
specifically proposed making properties part of the interface for... basically 
all the reasons given here.

My preference would be to add property accessors in 8.2 (at least the 
asymmetric visibility part), and then redefine `readonly` properties as a 
shorthand for a "get only" implicit accessor property; which, if I recall 
correctly, is essentially the same semantics as `readonly`.  (I didn't check 
the RFC; I'm going by memory here.)  That would include interface properties by 
nature.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Readonly properties and interfaces

[Brent Roose]

Hi internals

With the readonly properties RFC almost certainly accepted, I'd like to discuss 
an idea that's slightly related to them.

One of the problems that readonly properties solve is that they reduce the 
overhead of writing getters and setters. This is especially noticeable in 
objects that hold lots of data — data transfer objects, value objects, 
entities. And while public readonly properties will be a style of programming 
that not everyone likes, it's clear from the vote on the readonly RFC, as well 
as the community feedback, that it's a feature wanted by many.

That brings me to interfaces: currently we're only allowed to define methods on 
interfaces; historically this makes sense, since interfaces are meant to define 
behaviour, and not the implementation. Most OO language define behaviour using 
methods, and state using properties, which in turn are used to define the 
implementation.

But now, readonly properties are added.

Suddenly, class properties aren't just used for state anymore, they are also 
used to expose that state in an immutable way to the outside, where we'd use 
public getters (behaviour) and private properties (state) in the past, we can 
now combine them as public readonly properties. Wouldn't that imply that there 
are at least some cases where interface properties could also make sense?

A simple example:

Imagine we've got 10 different classes that share some behaviour: they are 
identifiable by a UUID. Next, imagine we've got a function that can 
specifically work with all classes that have a UUID. Proper OO teaches us to 
write an interface for this behaviour `Identifiable` or `HasUuid` or something 
alike. This interface would probably require its implementers to expose a 
`getUuid(): string` method. 

Without interfaces being able to define properties, we'll now have to implement 
a `getUuid()` method on all our 10 classes, nullifying the advantage we got 
from using `public readonly string $uuid` in the first place. If, on the other 
hand, this functionality was supported, we could write our interface like so, 
and wouldn't have to worry about any more boilerplate code:

```
interface HasUuid
{
public readonly string $uuid;
}
```

With the addition of readonly properties, now seems like a good time to discuss 
changing these rules. I realise these questions touch the core ideas of OO, so 
I reckon some people might have another opinion and I'd like to hear your 
thoughts.

To give you some more reading material, there is a precedent for interface 
properties in other languages:

- TypeScript supports them [1]
- C# supports them, albeit using property accessors [2]
- Swift supports them via Protocols [3]

Looking forward to hearing your thoughts.

Kind regards
Brent

[1] https://www.typescriptlang.org/docs/handbook/type-compatibility.html 
 
[2] 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
 

 
[3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 
 

Re: [PHP-DEV] Readonly properties and interfaces

[Pierre]

Le 07/07/2021 à 14:32, Brent Roose a écrit :

Hi internals

With the readonly properties RFC almost certainly accepted, I'd like to discuss 
an idea that's slightly related to them.

One of the problems that readonly properties solve is that they reduce the 
overhead of writing getters and setters. This is especially noticeable in 
objects that hold lots of data — data transfer objects, value objects, 
entities. And while public readonly properties will be a style of programming 
that not everyone likes, it's clear from the vote on the readonly RFC, as well 
as the community feedback, that it's a feature wanted by many.

That brings me to interfaces: currently we're only allowed to define methods on 
interfaces; historically this makes sense, since interfaces are meant to define 
behaviour, and not the implementation. Most OO language define behaviour using 
methods, and state using properties, which in turn are used to define the 
implementation.

But now, readonly properties are added.

Suddenly, class properties aren't just used for state anymore, they are also 
used to expose that state in an immutable way to the outside, where we'd use 
public getters (behaviour) and private properties (state) in the past, we can 
now combine them as public readonly properties. Wouldn't that imply that there 
are at least some cases where interface properties could also make sense?

A simple example:

Imagine we've got 10 different classes that share some behaviour: they are 
identifiable by a UUID. Next, imagine we've got a function that can 
specifically work with all classes that have a UUID. Proper OO teaches us to 
write an interface for this behaviour `Identifiable` or `HasUuid` or something 
alike. This interface would probably require its implementers to expose a 
`getUuid(): string` method.

Without interfaces being able to define properties, we'll now have to implement 
a `getUuid()` method on all our 10 classes, nullifying the advantage we got 
from using `public readonly string $uuid` in the first place. If, on the other 
hand, this functionality was supported, we could write our interface like so, 
and wouldn't have to worry about any more boilerplate code:

```
interface HasUuid
{
 public readonly string $uuid;
}
```

With the addition of readonly properties, now seems like a good time to discuss 
changing these rules. I realise these questions touch the core ideas of OO, so 
I reckon some people might have another opinion and I'd like to hear your 
thoughts.

To give you some more reading material, there is a precedent for interface 
properties in other languages:

- TypeScript supports them [1]
- C# supports them, albeit using property accessors [2]
- Swift supports them via Protocols [3]

Looking forward to hearing your thoughts.

Kind regards
Brent

[1] https://www.typescriptlang.org/docs/handbook/type-compatibility.html 

[2] 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
 

[3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 



Hello,

I agree, properties in interfaces would be very useful. It would allow 
me to get rid of many traits I wrote until now. I can live without it, 
but having it would be great help in many use cases I'm confronted with 
on a daily basis.


--

Regards,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php