Re: readonly properties

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

On Thu, Aug 12, 2021 at 9:16 PM Marc <marc@mabe.berlin> 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!