Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RFC - Immutable classes »

RFC - Immutable classes

php.internals

Silvio Marijić

10 years ago
Hi, I would need your help with one idea. I'm working on one RFC that I'm would like to submit. Idea is that after you initialize object eg. after constructor returns, object would be locked, and you wouldn't be able to change properties on that object anymore. It would like this: <?php immutable class Email {
> public $email; > public function __construct($email){ > $this->email = $email; > } > } > $email = new Email("example@email.com");
After instance of class is created, object is "frozen" so call like this $email->email = "new@email.com"; Would result in error. I have already implementation up to certain degree, but I need one advice from more experienced developers. Where is the place where I could put logic to lock object after the constructor has finished? Maybe in zend vm on ZEND_NEW token? Some constraints are needed: 1. Child class that extends immutable class must be defined as immutable also. 2. If property on immutable class contains object, it must be instance of immutable class. 3. You can not have immutability per property, it either whole class or none. Thank you all in advance.
-- Silvio Marijić Software Engineer 2e Systems

Michał Brzuchalski

10 years ago
Hi Silvio, Look into my talk about final properties https://marc.info/? t=145979255800003&r=1&w=2 maybe there would be something usefull. There is also talk about mutable and immutable properties and other class modifiers also about var and val. I'm not sure that it should be class midifier rather than proprty modifier keyword. regards,
-- Michał Brzuchalski 2016-08-08 12:31 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: > Hi, > > I would need your help with one idea. I'm working on one RFC that I'm would > like to submit. Idea is that after you initialize object eg. after > constructor returns, object would be locked, and you wouldn't be able to > change properties on that object anymore. It would like this: > > <?php > > immutable class Email { > > public $email; > > public function __construct($email){ > > $this->email = $email; > > } > > } > > $email = new Email("example@email.com"); > > > > After instance of class is created, object is "frozen" so call like this > > $email->email = "new@email.com"; > > > Would result in error. > > I have already implementation up to certain degree, but I need one advice > from more experienced developers. Where is the place where I could put > logic to lock object after the constructor has finished? Maybe in zend vm > on ZEND_NEW token? > > Some constraints are needed: > > 1. Child class that extends immutable class must be defined as immutable > also. > 2. If property on immutable class contains object, it must be instance > of immutable class. > 3. You can not have immutability per property, it either whole class or > none. > > Thank you all in advance. > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- pozdrawiam -- Michał Brzuchalski

Silvio Marijić

10 years ago
I see your standpoint, but I think it could cause confusion because of final classes. I think "immutable" is more suited here. What I try to achieve is something similar like case classes in Scala. Best regards, 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>:
> Hi Silvio, > > Look into my talk about final properties https://marc.info/? > t=145979255800003&r=1&w=2 maybe there would be something usefull. > There is also talk about mutable and immutable properties and other class > modifiers also about var and val. > I'm not sure that it should be class midifier rather than proprty modifier > keyword. > > regards, > -- > Michał Brzuchalski > > 2016-08-08 12:31 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: > >> Hi, >> >> I would need your help with one idea. I'm working on one RFC that I'm >> would >> like to submit. Idea is that after you initialize object eg. after >> constructor returns, object would be locked, and you wouldn't be able to >> change properties on that object anymore. It would like this: >> >> <?php >> >> immutable class Email { >> > public $email; >> > public function __construct($email){ >> > $this->email = $email; >> > } >> > } >> > $email = new Email("example@email.com"); >> >> >> >> After instance of class is created, object is "frozen" so call like this >> >> $email->email = "new@email.com"; >> >> >> Would result in error. >> >> I have already implementation up to certain degree, but I need one advice >> from more experienced developers. Where is the place where I could put >> logic to lock object after the constructor has finished? Maybe in zend vm >> on ZEND_NEW token? >> >> Some constraints are needed: >> >> 1. Child class that extends immutable class must be defined as >> immutable >> also. >> 2. If property on immutable class contains object, it must be instance >> of immutable class. >> 3. You can not have immutability per property, it either whole class or >> none. >> >> Thank you all in advance. >> >> -- >> Silvio Marijić >> Software Engineer >> 2e Systems >> > > > > -- > pozdrawiam > -- > Michał Brzuchalski >
-- Silvio Marijić Software Engineer 2e Systems

Silvio Marijić

10 years ago
Btw, I was not aware that there was already conversation on immutable classes. 2016-08-08 14:31 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>:
> I see your standpoint, but I think it could cause confusion because of > final classes. I think "immutable" is more suited here. > What I try to achieve is something similar like case classes in Scala. > > Best regards, > > 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: > >> Hi Silvio, >> >> Look into my talk about final properties https://marc.info/? >> t=145979255800003&r=1&w=2 maybe there would be something usefull. >> There is also talk about mutable and immutable properties and other class >> modifiers also about var and val. >> I'm not sure that it should be class midifier rather than proprty >> modifier keyword. >> >> regards, >> -- >> Michał Brzuchalski >> >> 2016-08-08 12:31 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: >> >>> Hi, >>> >>> I would need your help with one idea. I'm working on one RFC that I'm >>> would >>> like to submit. Idea is that after you initialize object eg. after >>> constructor returns, object would be locked, and you wouldn't be able to >>> change properties on that object anymore. It would like this: >>> >>> <?php >>> >>> immutable class Email { >>> > public $email; >>> > public function __construct($email){ >>> > $this->email = $email; >>> > } >>> > } >>> > $email = new Email("example@email.com"); >>> >>> >>> >>> After instance of class is created, object is "frozen" so call like this >>> >>> $email->email = "new@email.com"; >>> >>> >>> Would result in error. >>> >>> I have already implementation up to certain degree, but I need one advice >>> from more experienced developers. Where is the place where I could put >>> logic to lock object after the constructor has finished? Maybe in zend vm >>> on ZEND_NEW token? >>> >>> Some constraints are needed: >>> >>> 1. Child class that extends immutable class must be defined as >>> immutable >>> also. >>> 2. If property on immutable class contains object, it must be instance >>> of immutable class. >>> 3. You can not have immutability per property, it either whole class >>> or >>> none. >>> >>> Thank you all in advance. >>> >>> -- >>> Silvio Marijić >>> Software Engineer >>> 2e Systems >>> >> >> >> >> -- >> pozdrawiam >> -- >> Michał Brzuchalski >> > > > > -- > Silvio Marijić > Software Engineer > 2e Systems >
-- Silvio Marijić Software Engineer 2e Systems

Michał Brzuchalski

10 years ago
Sure my final properties was first thought, lately in discuccion it turns into immutable, sealed and final see here https://marc.info/?l=php-internals&m=146005058530881&w=2 Have you also read about Immutable modifier from last year? http://marc.info/?t=144766539400001&r=1&w=2 it's exactly about immutable classes! 2016-08-08 14:46 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>:
> Btw, I was not aware that there was already conversation on immutable > classes. > > 2016-08-08 14:31 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: > >> I see your standpoint, but I think it could cause confusion because of >> final classes. I think "immutable" is more suited here. >> What I try to achieve is something similar like case classes in Scala. >> >> Best regards, >> >> 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: >> >>> Hi Silvio, >>> >>> Look into my talk about final properties https://marc.info/? >>> t=145979255800003&r=1&w=2 maybe there would be something usefull. >>> There is also talk about mutable and immutable properties and other >>> class modifiers also about var and val. >>> I'm not sure that it should be class midifier rather than proprty >>> modifier keyword. >>> >>> regards, >>> -- >>> Michał Brzuchalski >>> >>> 2016-08-08 12:31 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: >>> >>>> Hi, >>>> >>>> I would need your help with one idea. I'm working on one RFC that I'm >>>> would >>>> like to submit. Idea is that after you initialize object eg. after >>>> constructor returns, object would be locked, and you wouldn't be able to >>>> change properties on that object anymore. It would like this: >>>> >>>> <?php >>>> >>>> immutable class Email { >>>> > public $email; >>>> > public function __construct($email){ >>>> > $this->email = $email; >>>> > } >>>> > } >>>> > $email = new Email("example@email.com"); >>>> >>>> >>>> >>>> After instance of class is created, object is "frozen" so call like this >>>> >>>> $email->email = "new@email.com"; >>>> >>>> >>>> Would result in error. >>>> >>>> I have already implementation up to certain degree, but I need one >>>> advice >>>> from more experienced developers. Where is the place where I could put >>>> logic to lock object after the constructor has finished? Maybe in zend >>>> vm >>>> on ZEND_NEW token? >>>> >>>> Some constraints are needed: >>>> >>>> 1. Child class that extends immutable class must be defined as >>>> immutable >>>> also. >>>> 2. If property on immutable class contains object, it must be >>>> instance >>>> of immutable class. >>>> 3. You can not have immutability per property, it either whole class >>>> or >>>> none. >>>> >>>> Thank you all in advance. >>>> >>>> -- >>>> Silvio Marijić >>>> Software Engineer >>>> 2e Systems >>>> >>> >>> >>> >>> -- >>> pozdrawiam >>> -- >>> Michał Brzuchalski >>> >> >> >> >> -- >> Silvio Marijić >> Software Engineer >> 2e Systems >> > > > > -- > Silvio Marijić > Software Engineer > 2e Systems >
-- pozdrawiam -- Michał Brzuchalski

Alex Sky

10 years ago
May be better to do as immutable arrays? const = new Email; it will be a super global immutable instance of Email.

Alex Sky

10 years ago
May be better to do as immutable arrays? const EmailObject = new Email; It will be a super global immutable instance of Email.

Michał Brzuchalski

10 years ago
2016-08-08 14:47 GMT+02:00 S.A.N <ua.san.alex@gmail.com>:
> May be better to do as immutable arrays? > > const = new Email; > > it will be a super global immutable instance of Email. >
I think you've missunderstood concept of immutable classes.
-- pozdrawiam -- Michał Brzuchalski

Silvio Marijić

10 years ago
@Michal, well no I did read it. I see that there is not much going on there since last year. Did you tried to implement it ? 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>:
> > 2016-08-08 14:47 GMT+02:00 S.A.N <ua.san.alex@gmail.com>: > >> May be better to do as immutable arrays? >> >> const = new Email; >> >> it will be a super global immutable instance of Email. >> > > I think you've missunderstood concept of immutable classes. > > > -- > pozdrawiam > -- > Michał Brzuchalski >
-- Silvio Marijić Software Engineer 2e Systems

Michał Brzuchalski

10 years ago
@Silvio I've tried to implement final https://github.com/php/php-src/compare/master...brzuchal:final-properties but haven't found time to implement immutable and sealed, AFAIK I had problems with OPcache enabled, you need to remember to run every test after compile with opcache enabled in CLI. 2016-08-08 15:00 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>:
> @Michal, well no I did read it. I see that there is not much going on > there since last year. Did you tried to implement it ? > > 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: > >> >> 2016-08-08 14:47 GMT+02:00 S.A.N <ua.san.alex@gmail.com>: >> >>> May be better to do as immutable arrays? >>> >>> const = new Email; >>> >>> it will be a super global immutable instance of Email. >>> >> >> I think you've missunderstood concept of immutable classes. >> >> >> -- >> pozdrawiam >> -- >> Michał Brzuchalski >> > > > > -- > Silvio Marijić > Software Engineer > 2e Systems >
-- pozdrawiam -- Michał Brzuchalski

Silvio Marijić

10 years ago
@Michal Would you consider cooperating on implementing immutable and sealed modifiers? 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>:
> @Silvio I've tried to implement final https://github.com/php/ > php-src/compare/master...brzuchal:final-properties but haven't found time > to implement immutable and sealed, AFAIK I had problems with OPcache > enabled, you need to remember to run every test after compile with opcache > enabled in CLI. > > 2016-08-08 15:00 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: > >> @Michal, well no I did read it. I see that there is not much going on >> there since last year. Did you tried to implement it ? >> >> 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: >> >>> >>> 2016-08-08 14:47 GMT+02:00 S.A.N <ua.san.alex@gmail.com>: >>> >>>> May be better to do as immutable arrays? >>>> >>>> const = new Email; >>>> >>>> it will be a super global immutable instance of Email. >>>> >>> >>> I think you've missunderstood concept of immutable classes. >>> >>> >>> -- >>> pozdrawiam >>> -- >>> Michał Brzuchalski >>> >> >> >> >> -- >> Silvio Marijić >> Software Engineer >> 2e Systems >> > > > > -- > pozdrawiam > -- > Michał Brzuchalski >
-- Silvio Marijić Software Engineer 2e Systems

Michał Brzuchalski

10 years ago
It is great to hear somone is interested so why not. My lately discussion found usefull implementing 3 keywords, such as: 1. *immutable* for the functionality you are currently working on. 2. *sealed* for the above plus type not changeable. 3. *final* for the above plus not being overridable. But all of them should be implemented in different RFC's starting from Immutable because it's base point to toher two keywords. Whole idea needs refreshing discussion to clarify idea so it can success. 2016-08-08 15:23 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>:
> @Michal Would you consider cooperating on implementing immutable and > sealed modifiers? > > 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: > >> @Silvio I've tried to implement final https://github.com/php/p >> hp-src/compare/master...brzuchal:final-properties but haven't found time >> to implement immutable and sealed, AFAIK I had problems with OPcache >> enabled, you need to remember to run every test after compile with opcache >> enabled in CLI. >> >> 2016-08-08 15:00 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: >> >>> @Michal, well no I did read it. I see that there is not much going on >>> there since last year. Did you tried to implement it ? >>> >>> 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: >>> >>>> >>>> 2016-08-08 14:47 GMT+02:00 S.A.N <ua.san.alex@gmail.com>: >>>> >>>>> May be better to do as immutable arrays? >>>>> >>>>> const = new Email; >>>>> >>>>> it will be a super global immutable instance of Email. >>>>> >>>> >>>> I think you've missunderstood concept of immutable classes. >>>> >>>> >>>> -- >>>> pozdrawiam >>>> -- >>>> Michał Brzuchalski >>>> >>> >>> >>> >>> -- >>> Silvio Marijić >>> Software Engineer >>> 2e Systems >>> >> >> >> >> -- >> pozdrawiam >> -- >> Michał Brzuchalski >> > > > > -- > Silvio Marijić > Software Engineer > 2e Systems >
-- pozdrawiam -- Michał Brzuchalski

Silvio Marijić

10 years ago
It's great that you are up of this. I think it will be great to see this one in action. I agree that we should separate them into separate RFC-s. 2016-08-08 15:51 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>:
> It is great to hear somone is interested so why not. My lately discussion > found usefull implementing 3 keywords, such as: > 1. *immutable* for the functionality you are currently working on. > 2. *sealed* for the above plus type not changeable. > 3. *final* for the above plus not being overridable. > > But all of them should be implemented in different RFC's starting from > Immutable because it's base point to toher two keywords. > Whole idea needs refreshing discussion to clarify idea so it can success. > > 2016-08-08 15:23 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: > >> @Michal Would you consider cooperating on implementing immutable and >> sealed modifiers? >> >> 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: >> >>> @Silvio I've tried to implement final https://github.com/php/p >>> hp-src/compare/master...brzuchal:final-properties but haven't found >>> time to implement immutable and sealed, AFAIK I had problems with OPcache >>> enabled, you need to remember to run every test after compile with opcache >>> enabled in CLI. >>> >>> 2016-08-08 15:00 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>: >>> >>>> @Michal, well no I did read it. I see that there is not much going on >>>> there since last year. Did you tried to implement it ? >>>> >>>> 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski <michal@brzuchalski.com>: >>>> >>>>> >>>>> 2016-08-08 14:47 GMT+02:00 S.A.N <ua.san.alex@gmail.com>: >>>>> >>>>>> May be better to do as immutable arrays? >>>>>> >>>>>> const = new Email; >>>>>> >>>>>> it will be a super global immutable instance of Email. >>>>>> >>>>> >>>>> I think you've missunderstood concept of immutable classes. >>>>> >>>>> >>>>> -- >>>>> pozdrawiam >>>>> -- >>>>> Michał Brzuchalski >>>>> >>>> >>>> >>>> >>>> -- >>>> Silvio Marijić >>>> Software Engineer >>>> 2e Systems >>>> >>> >>> >>> >>> -- >>> pozdrawiam >>> -- >>> Michał Brzuchalski >>> >> >> >> >> -- >> Silvio Marijić >> Software Engineer >> 2e Systems >> > > > > -- > pozdrawiam > -- > Michał Brzuchalski >
-- Silvio Marijić Software Engineer 2e Systems

Fred Emmott

9 years ago
I see Reflection is still todo; should there be a similar escape hatch to ReflectionMethod::setAccessible()? This would allow things like: https://gist.github.com/fredemmott/01ad55c0c03c8d7ba62bbd6e9fb23686 <https://gist.github.com/fredemmott/01ad55c0c03c8d7ba62bbd6e9fb23686> (apologies for the hack-like syntax) - the ‘every property must be a constructor parameter’ approach in the RFC seems like it would rapidly become unwieldy for classes with a large number of properties. Regards, - Fred On Aug 8, 2016, at 3:31 AM, Silvio Marijić <marijic.silvio@gmail.com> wrote:

Silvio Marijić

9 years ago
@Fred Thanks for taking interest. I still need to fully patch reflection extension for this. We had more important discussions in the past two weeks. Cheers, Silvio 2016-09-09 21:46 GMT+02:00 Fred Emmott <fred@fredemmott.co.uk>:
> I see Reflection is still todo; should there be a similar escape hatch to > ReflectionMethod::setAccessible()? > > This would allow things like: https://gist.github.com/fredemmott/ > 01ad55c0c03c8d7ba62bbd6e9fb23686 (apologies for the hack-like syntax) - > the ‘every property must be a constructor parameter’ approach in the RFC > seems like it would rapidly become unwieldy for classes with a large number > of properties. > > Regards, > - Fred > > > On Aug 8, 2016, at 3:31 AM, Silvio Marijić <marijic.silvio@gmail.com> > wrote: > > > Hi, > > I would need your help with one idea. I'm working on one RFC that I'm would > like to submit. Idea is that after you initialize object eg. after > constructor returns, object would be locked, and you wouldn't be able to > change properties on that object anymore. It would like this: > > <?php > > immutable class Email { > > public $email; > public function __construct($email){ > $this->email = $email; > } > } > $email = new Email("example@email.com"); > > > > > After instance of class is created, object is "frozen" so call like this > > $email->email = "new@email.com"; > > > Would result in error. > > I have already implementation up to certain degree, but I need one advice > from more experienced developers. Where is the place where I could put > logic to lock object after the constructor has finished? Maybe in zend vm > on ZEND_NEW token? > > Some constraints are needed: > > 1. Child class that extends immutable class must be defined as immutable > also. > 2. If property on immutable class contains object, it must be instance > of immutable class. > 3. You can not have immutability per property, it either whole class or > none. > > Thank you all in advance. > > -- > Silvio Marijić > Software Engineer > 2e Systems > > >
-- Silvio Marijić Software Engineer 2e Systems

Silvio Marijić

9 years ago
It will be patched before this RFC goes into official discussion. 2016-09-09 22:01 GMT+02:00 Silvio Marijić <marijic.silvio@gmail.com>:
> @Fred > > Thanks for taking interest. I still need to fully patch reflection > extension for this. We had more important discussions in the past two weeks. > > Cheers, > Silvio > > 2016-09-09 21:46 GMT+02:00 Fred Emmott <fred@fredemmott.co.uk>: > >> I see Reflection is still todo; should there be a similar escape hatch >> to ReflectionMethod::setAccessible()? >> >> This would allow things like: https://gist.github.com/ >> fredemmott/01ad55c0c03c8d7ba62bbd6e9fb23686 (apologies for the hack-like >> syntax) - the ‘every property must be a constructor parameter’ approach in >> the RFC seems like it would rapidly become unwieldy for classes with a >> large number of properties. >> >> Regards, >> - Fred >> >> >> On Aug 8, 2016, at 3:31 AM, Silvio Marijić <marijic.silvio@gmail.com> >> wrote: >> >> >> Hi, >> >> I would need your help with one idea. I'm working on one RFC that I'm >> would >> like to submit. Idea is that after you initialize object eg. after >> constructor returns, object would be locked, and you wouldn't be able to >> change properties on that object anymore. It would like this: >> >> <?php >> >> immutable class Email { >> >> public $email; >> public function __construct($email){ >> $this->email = $email; >> } >> } >> $email = new Email("example@email.com"); >> >> >> >> >> After instance of class is created, object is "frozen" so call like this >> >> $email->email = "new@email.com"; >> >> >> Would result in error. >> >> I have already implementation up to certain degree, but I need one advice >> from more experienced developers. Where is the place where I could put >> logic to lock object after the constructor has finished? Maybe in zend vm >> on ZEND_NEW token? >> >> Some constraints are needed: >> >> 1. Child class that extends immutable class must be defined as immutable >> also. >> 2. If property on immutable class contains object, it must be instance >> of immutable class. >> 3. You can not have immutability per property, it either whole class or >> none. >> >> Thank you all in advance. >> >> -- >> Silvio Marijić >> Software Engineer >> 2e Systems >> >> >> > > > -- > Silvio Marijić > Software Engineer > 2e Systems >
-- Silvio Marijić Software Engineer 2e Systems

Fleshgrinder

9 years ago
On 9/9/2016 10:02 PM, Silvio Marijić wrote:
> It will be patched before this RFC goes into official discussion. >
That explains why all the rewritten tests I provided for Reflection fail: https://github.com/brzuchal/php-src/pull/1 Should I create this PR against another repository? I created it against the one that was last posted for review but no clue which would be right one to contribute here?!?
-- Richard "Fleshgrinder" Fussenegger

Silvio Marijić

9 years ago
@Fleshgrinder, Well since implementation is still underway I think the best ways would be to wait untill we finish implementation, and then we all can do the review to make sure everything is in place. 2016-09-09 23:16 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:
> On 9/9/2016 10:02 PM, Silvio Marijić wrote: > > It will be patched before this RFC goes into official discussion. > > > > That explains why all the rewritten tests I provided for Reflection fail: > > https://github.com/brzuchal/php-src/pull/1 > > Should I create this PR against another repository? I created it against > the one that was last posted for review but no clue which would be right > one to contribute here?!? > > -- > Richard "Fleshgrinder" Fussenegger > >
-- Silvio Marijić Software Engineer 2e Systems