Re: [PHP-DEV] RFC - Immutable classes

2016-09-15 Thread Fleshgrinder
On 9/14/2016 7:25 PM, Mathieu Rochette wrote: > yeah the example is not that great, I'll usually want to clone to > avoid calling a constructor with to many parameters (or a constructor > doing too many things not needed here) > That's exactly the reason why we want the _clone_ modifier. :) On

Re: [PHP-DEV] RFC - Immutable classes

2016-09-14 Thread Mathieu Rochette
Sent from my Alcatel Onetouch Idol 3 (4.7) On Sep 14, 2016 7:08 PM, Fleshgrinder wrote: > > On 9/13/2016 11:38 PM, Mathieu Rochette wrote: > > I agree that blocking clone seems unnecessary. I also don't see why it > > is useful to have "clone" methods. Why not let

Re: [PHP-DEV] RFC - Immutable classes

2016-09-14 Thread Fleshgrinder
On 9/13/2016 11:38 PM, Mathieu Rochette wrote: > I agree that blocking clone seems unnecessary. I also don't see why it > is useful to have "clone" methods. Why not let "clone $this" produce a > copy that is open to modification within the scope it's cloned in ? or, > why would you limit yourself

Re: [PHP-DEV] RFC - Immutable classes

2016-09-13 Thread Mathieu Rochette
On 09/13/2016 02:07 AM, Larry Garfield wrote: > On 09/12/2016 06:47 PM, Stephen Reay wrote: >>> Ah, I did see that one, but there was a lot of discussion after it >>> so I thought the idea evolved. Response below based on skimming the >>> responses after that as well... >>> >>> It sounds like

Re: [PHP-DEV] RFC - Immutable classes

2016-09-13 Thread Lester Caine
On 13/09/16 00:47, Stephen Reay wrote: > Regarding identity, I’m going to refer back to the DateTimeImmutable class. I > know its not the same implementation, but honestly I don’t think that > matters. Developers use PHP because they generally *don’t* have to worry > about the internal details

Re: [PHP-DEV] RFC - Immutable classes

2016-09-13 Thread Michał Brzuchalski
Proposed operator overloading and magic methods to compare with other objects is very good idea, I like it a lot, there even may be additional restriction provided with my other RFC https://wiki.php.net/rfc/object-typehint But I think this goal should be provided in separate RFC as it is very

Re: [PHP-DEV] RFC - Immutable classes

2016-09-13 Thread Fleshgrinder
Thanks a lot for your feedback. I like the clone idea too and I also see no harm in allowing them in any context rather than only in immutable classes. I am really against the transformer keyword, don't ask me why, I just don't like it at all. :P I mentioned before that PHP should allow for

Re: [PHP-DEV] RFC - Immutable classes

2016-09-12 Thread Larry Garfield
On 09/12/2016 06:47 PM, Stephen Reay wrote: Ah, I did see that one, but there was a lot of discussion after it so I thought the idea evolved. Response below based on skimming the responses after that as well... It sounds like there's more that needs to go on, though. It sounds like that

Re: [PHP-DEV] RFC - Immutable classes

2016-09-12 Thread Stephen Reay
Hi Larry, > On 13 Sep 2016, at 03:11, Larry Garfield wrote: > > On 09/12/2016 11:40 AM, Fleshgrinder wrote: >> On 9/11/2016 10:04 PM, Larry Garfield wrote: >>> On 09/10/2016 05:55 AM, Fleshgrinder wrote: @Larry what do you think about the CoW proposal? >>> I'm

Re: [PHP-DEV] RFC - Immutable classes

2016-09-12 Thread Larry Garfield
On 09/12/2016 11:40 AM, Fleshgrinder wrote: On 9/11/2016 10:04 PM, Larry Garfield wrote: On 09/10/2016 05:55 AM, Fleshgrinder wrote: @Larry what do you think about the CoW proposal? I'm afraid I got lost in the thread somewhere with the back and forth about implementation details. Can you

Re: [PHP-DEV] RFC - Immutable classes

2016-09-12 Thread Fleshgrinder
On 9/11/2016 10:04 PM, Larry Garfield wrote: > On 09/10/2016 05:55 AM, Fleshgrinder wrote: >> @Larry what do you think about the CoW proposal? > > I'm afraid I got lost in the thread somewhere with the back and forth > about implementation details. Can you repost the current proposal, or > has

Re: [PHP-DEV] RFC - Immutable classes

2016-09-12 Thread Silvio Marijić
@Larry RFC is not updated with the solution for cloning yet. So far I did add changes on which we have agreed on. Currently we have to candidates: First one is to have copy on write (As Christoph pointed out, we had that in PHP 4). Second proposal is to introduce "transformer" keyword as a

Re: [PHP-DEV] RFC - Immutable classes

2016-09-11 Thread Larry Garfield
On 09/10/2016 05:55 AM, Fleshgrinder wrote: So? Where are we now? CoW is definitely doable and I personally think that it's the best approach because the engine has full control that nothing goes south. I also do not think that it's magic in any way since developers have to add the _immutable_

Re: [PHP-DEV] RFC - Immutable classes

2016-09-10 Thread Silvio Marijić
I agree. Will add this feature to RFC also Cheers On Sep 10, 2016 8:02 PM, "Marco Pivetta" wrote: > On Sat, Sep 10, 2016 at 7:49 PM, Niklas Keller wrote: > >> 2016-09-10 19:41 GMT+02:00 Silvio Marijić : >> >> > @Fleshgrinder, >> >

Re: [PHP-DEV] RFC - Immutable classes

2016-09-10 Thread Marco Pivetta
On Sat, Sep 10, 2016 at 7:49 PM, Niklas Keller wrote: > 2016-09-10 19:41 GMT+02:00 Silvio Marijić : > > > @Fleshgrinder, > > > > While I'm not sure at the moment about CoW, I can agree that we should > add > > immutable keyword as a interface modifier

Re: [PHP-DEV] RFC - Immutable classes

2016-09-10 Thread Niklas Keller
2016-09-10 19:41 GMT+02:00 Silvio Marijić : > @Fleshgrinder, > > While I'm not sure at the moment about CoW, I can agree that we should add > immutable keyword as a interface modifier to make sure all classes > implementing must be immutable. As interfaces can't have

Re: [PHP-DEV] RFC - Immutable classes

2016-09-10 Thread Silvio Marijić
@Fleshgrinder, While I'm not sure at the moment about CoW, I can agree that we should add immutable keyword as a interface modifier to make sure all classes implementing must be immutable. On Sep 10, 2016 12:55 PM, "Fleshgrinder" wrote: > So? Where are we now? CoW is

Re: [PHP-DEV] RFC - Immutable classes

2016-09-10 Thread Fleshgrinder
So? Where are we now? CoW is definitely doable and I personally think that it's the best approach because the engine has full control that nothing goes south. I also do not think that it's magic in any way since developers have to add the _immutable_ keyword explicitly to the class. That this

Re: [PHP-DEV] RFC - Immutable classes

2016-09-09 Thread Silvio Marijić
@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 : > On 9/9/2016 10:02 PM,

Re: [PHP-DEV] RFC - Immutable classes

2016-09-09 Thread Fleshgrinder
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

Re: [PHP-DEV] RFC - Immutable classes

2016-09-09 Thread Silvio Marijić
It will be patched before this RFC goes into official discussion. 2016-09-09 22:01 GMT+02:00 Silvio Marijić : > @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. >

Re: [PHP-DEV] RFC - Immutable classes

2016-09-09 Thread Silvio Marijić
@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 : > I see Reflection is still todo; should there be a similar

Re: [PHP-DEV] RFC - Immutable classes

2016-09-09 Thread Fred Emmott
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

Re: [PHP-DEV] RFC - Immutable classes

2016-09-08 Thread Christoph M. Becker
On 08.09.2016 at 09:41, Silvio Marijić wrote: > I get the nostalgia :) > I think that *zend_compare_symbol_tables* compares only hash tables whether > they contain same properties regardless of the values. What I wanted to show was that PHP 4 objects implemented copy-on-write semantics; the test

Re: [PHP-DEV] RFC - Immutable classes

2016-09-08 Thread Silvio Marijić
@Christoph I get the nostalgia :) I think that *zend_compare_symbol_tables* compares only hash tables whether they contain same properties regardless of the values. 2016-09-07 20:44 GMT+02:00 Silvio Marijić : > @Fleshgrinder > > I will make changes that if immutable

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
@Fleshgrinder I will make changes that if immutable objects are being compared that they will be compared by value rather then hash On Sep 7, 2016 8:27 PM, "Christoph M. Becker" wrote: > On 07.09.2016 at 20:11, Fleshgrinder wrote: > > > On 9/7/2016 8:57 AM, Michał Brzuchalski

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Christoph M. Becker
On 07.09.2016 at 20:11, Fleshgrinder wrote: > On 9/7/2016 8:57 AM, Michał Brzuchalski wrote: > >> AFAIK CoW in case of objects would be impossible to implement. > > Nothing is impossible. :) > > We have full access to the real object inside of zend_std_write_property > and can easily clone it,

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Fleshgrinder
First a general comment on cloning. Nothing bad happens if we allow cloning other than a performance hit. But only if we ensure that immutable objects are identified by value and not by the usual object hash. In case of the latter, as it is implemented right now, you end up with an exact copy but

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
@Lester I might have expressed my self in a wrong way, there is not wrong with encapsulation. Thing is that there is no proper support and unified solution from the language. There are much examples of real world cases where this can be useful. I understand that same behaviour can be achieved on

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Mathieu Rochette
On 07/09/2016 15:09, Michał Brzuchalski wrote: @Mathieu How about that: https://gist.github.com/brzuchal/e7b721e22a19cca42ec0d1f597a23baf We've discussed this could be best option, when invoking `transformer` method (or whatever we call it) there is `$this = clone $this` invoked under the

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Lester Caine
On 07/09/16 10:28, Silvio Marijić wrote: > DateTimeImmutable does not prevent cloning because immutability is achieved > by encapsulation, and we want to get rid of the need of encapsulation in > our implementation of immutable objects. What is the problem with 'encapsulation'? By that I mean

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Michał Brzuchalski
@Mathieu How about that: https://gist.github.com/brzuchal/e7b721e22a19cca42ec0d1f597a23baf We've discussed this could be best option, when invoking `transformer` method (or whatever we call it) there is `$this = clone $this` invoked under the hood. 2016-09-07 14:53 GMT+02:00 Mathieu Rochette

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Mathieu Rochette
a few remarks on mutator methods: * It could be a nice way to solve the "create another one almost the same" use case. * I don't mind if $clone is an explicit parameter or magically available * what happens if I call other function/methods with this $clone before the end of the function

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Stephen Reay
Well crap I just realised I hadn’t hit reply-all several replies ago!. I also just noticed that you had mentioned about allowing property writes only in __construct and __clone last week, and asked about how it might look. I wasn’t subscribed then so I didn’t see the earlier discussions. I’ll

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
Ok, I have some time also so we can together try to write some initial implementation of that. 2016-09-07 14:10 GMT+02:00 Michał Brzuchalski : > Silvio, > > I can try with it tommorow, we'll see about that. > > > 2016-09-07 14:05 GMT+02:00 Silvio Marijić

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Michał Brzuchalski
Silvio, I can try with it tommorow, we'll see about that. 2016-09-07 14:05 GMT+02:00 Silvio Marijić : > Michal, how much work do you estimate it would take us to implement method > modificator solution? > > 2016-09-07 14:01 GMT+02:00 Michał Brzuchalski

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
Michal, how much work do you estimate it would take us to implement method modificator solution? 2016-09-07 14:01 GMT+02:00 Michał Brzuchalski : > Hi, > > Frozing an immutable object after it's creation is most important feature > of Immutable Classes. > Without it you

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Michał Brzuchalski
Hi, Frozing an immutable object after it's creation is most important feature of Immutable Classes. Without it you cannot have guarantee it's internal state is consistent as it was during creation. Having methods access to write is quite dangerous - think about CLosure binded to immutable object

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
@Stephan I am against that any kind of method can make modification on original object. Cloning can be allowed but for this use case where you would pass properties that are changing, we would have to modify syntax of clone On Sep 7, 2016 12:37 PM, "Stephen Reay"

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Stephen Reay
Hey Matheiu, Silvio, That is my main concern with the inability to clone from outside the class. I don’t think immutable should cause an error in this situation - if you really don’t want to allow users to create objects they can’t modify (which I understand) could clone on an immutable object

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
@Mathieu, Object can not be modified neither internally or externally, question is if you clone object where should we allow modification of cloned object On Sep 7, 2016 12:13 PM, "Mathieu Rochette" wrote: > > > On 07/09/2016 11:05, Stephen Reay wrote: > >> (Sorry for any

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Mathieu Rochette
On 07/09/2016 11:05, Stephen Reay wrote: (Sorry for any dupes, sent from wrong address originally) From a developer point of view, I would suggest that a feature should aim to be as clear to understand with as little “magic" as possible. If the goal of an immutable class is to allow

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Mathieu Rochette
On 07/09/2016 11:28, Silvio Marijić wrote: Hi Stephen, Cloning is disabled at the moment in implementation because you would end up with a object that you can not change, so you have no use of that. I'll change that as soon as we find some good solution for handling that. Your example is not

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
And also Fleshgrinder made a good point about comparing two immutable objects. They should be compared based on value, not on identity. 2016-09-07 11:28 GMT+02:00 Silvio Marijić : > Hi Stephen, > > Cloning is disabled at the moment in implementation because you would

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Silvio Marijić
Hi Stephen, Cloning is disabled at the moment in implementation because you would end up with a object that you can not change, so you have no use of that. I'll change that as soon as we find some good solution for handling that. Your example is not really clear to me. At what point we should

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Stephen Reay
(Sorry for any dupes, sent from wrong address originally) From a developer point of view, I would suggest that a feature should aim to be as clear to understand with as little “magic" as possible. If the goal of an immutable class is to allow public properties to be made read-only, my

Re: [PHP-DEV] RFC - Immutable classes

2016-09-07 Thread Michał Brzuchalski
06.09.2016 9:13 PM "Fleshgrinder" napisał(a): > > I understand the concerns of all of you very well and it's nice to see a > discussion around this topic. Fun fact, we are not the only ones with > these issues: https://github.com/dotnet/roslyn/issues/159 > > On 9/6/2016

Re: [PHP-DEV] RFC - Immutable classes

2016-09-06 Thread Fleshgrinder
I understand the concerns of all of you very well and it's nice to see a discussion around this topic. Fun fact, we are not the only ones with these issues: https://github.com/dotnet/roslyn/issues/159 On 9/6/2016 6:01 PM, Larry Garfield wrote: > How big of a need is it to allow returning $this

Re: [PHP-DEV] RFC - Immutable classes

2016-09-06 Thread Silvio Marijić
@Larry, Fact that $this in transformer method represents clone and the original object was my biggest concern, but again if you look at t from a point of view where that method describes transformation it doesn't look that bad. My initial idea was to introduce copy() method which would take as a

Re: [PHP-DEV] RFC - Immutable classes

2016-09-06 Thread Larry Garfield
On 09/05/2016 11:37 AM, Fleshgrinder wrote: On 9/5/2016 10:26 AM, Michał Brzuchalski wrote: I had a talk at Room11 and we discussed idea of `mutator` keyword. There were some concerns using `mutator` as a keyword - that's because immutable object is not being muted and also magically appeared

Re: [PHP-DEV] RFC - Immutable classes

2016-09-05 Thread Fleshgrinder
On 9/5/2016 4:21 AM, Michał Brzuchalski wrote: > You may begin with modifications on RFC eg. in a gist so we can all > discuss about it before putting on RFC, is that okay to you? Absolutely, that's how I thought about approaching it too because otherwise we might create a mess in the Wiki. On

Re: [PHP-DEV] RFC - Immutable classes

2016-09-05 Thread Michał Brzuchalski
I had a talk at Room11 and we discussed idea of `mutator` keyword. There were some concerns using `mutator` as a keyword - that's because immutable object is not being muted and also magically appeared `$clone` would be confusing. There's an idea of creating clone before function begins and

Re: [PHP-DEV] RFC - Immutable classes

2016-09-04 Thread Michał Brzuchalski
2016-09-04 22:38 GMT+02:00 Fleshgrinder : > On 9/4/2016 2:29 PM, Michał Brzuchalski wrote: > >> Providing `mutator` | `mut` keyword as method modifier sounds liek a > good > >> idea, > >> althought passing `$clone` parameter as first additional param could > break > >>

Re: [PHP-DEV] RFC - Immutable classes

2016-09-04 Thread Fleshgrinder
On 9/4/2016 2:29 PM, Michał Brzuchalski wrote: >> Providing `mutator` | `mut` keyword as method modifier sounds liek a good >> idea, >> althought passing `$clone` parameter as first additional param could break >> method declaration and would be misleading. >> >> Assuming mutator method is

Re: [PHP-DEV] RFC - Immutable classes

2016-09-04 Thread Michał Brzuchalski
2016-09-04 14:10 GMT+02:00 Michał Brzuchalski : > > > 2016-09-04 10:55 GMT+02:00 Fleshgrinder : > >> Hi Chris! >> >> On 9/3/2016 5:00 PM, Chris Riley wrote: >> > - Properties can be declared immutable. Immutable properties may only be >> > changed

Re: [PHP-DEV] RFC - Immutable classes

2016-09-04 Thread Michał Brzuchalski
2016-09-04 10:55 GMT+02:00 Fleshgrinder : > Hi Chris! > > On 9/3/2016 5:00 PM, Chris Riley wrote: > > - Properties can be declared immutable. Immutable properties may only be > > changed under two circumstances: a) In the objects constructor b) If they > > are null (This

Re: [PHP-DEV] RFC - Immutable classes

2016-09-04 Thread Fleshgrinder
Hi Chris! On 9/3/2016 5:00 PM, Chris Riley wrote: > - Properties can be declared immutable. Immutable properties may only be > changed under two circumstances: a) In the objects constructor b) If they > are null (This enables setter injection if required) > The constraint b) would make the

Re: [PHP-DEV] RFC - Immutable classes

2016-09-03 Thread Chris Riley
On 2 September 2016 at 15:59, Silvio Marijić wrote: > Michal I'm talking about __clone() callback after clone operation. But I > agree with you about syntax part. > > 2016-09-02 16:46 GMT+02:00 Michał Brzuchalski < > michal.brzuchal...@gmail.com> > : > > > 02.09.2016

Re: [PHP-DEV] RFC - Immutable classes

2016-09-03 Thread Fleshgrinder
Hey guys :) # Abstract Classes Establishing a contract that any child class of an abstract class has to be immutable is a totally valid use case in my opinion and it aids consistency. Otherwise we have the same situation as with final which I never understood. Actually, even interfaces could

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Silvio Marijić
Michal I'm talking about __clone() callback after clone operation. But I agree with you about syntax part. 2016-09-02 16:46 GMT+02:00 Michał Brzuchalski : > 02.09.2016 16:29 "Larry Garfield" napisał(a): > > > > On 09/02/2016 09:06 AM,

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Michał Brzuchalski
02.09.2016 16:29 "Larry Garfield" napisał(a): > > On 09/02/2016 09:06 AM, Silvio Marijić wrote: >> >> Well at the moment expection is thrown in case when you try to clone >> immutable object. But you do seem to have valid point there regarding >> __clone method. I'm

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Silvio Marijić
Basically I'm concerned about __clone() since you can not pass parameters 2016-09-02 16:44 GMT+02:00 Silvio Marijić : > Hi Larry, > I'm aware of that but we do have make some strong constraints there > otherwise we are undermining the strong guarantee of immutability. I

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Silvio Marijić
Hi Larry, I'm aware of that but we do have make some strong constraints there otherwise we are undermining the strong guarantee of immutability. I would agree to allow object modification only and only *inside* __construct() and __clone methods. I'm trying to come up with idea how would that look

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Larry Garfield
On 09/02/2016 09:06 AM, Silvio Marijić wrote: Well at the moment expection is thrown in case when you try to clone immutable object. But you do seem to have valid point there regarding __clone method. I'm definitely going to give it a thought. Best, Silvio. 2016-09-02 15:52 GMT+02:00 André

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Silvio Marijić
Well at the moment expection is thrown in case when you try to clone immutable object. But you do seem to have valid point there regarding __clone method. I'm definitely going to give it a thought. Best, Silvio. 2016-09-02 15:52 GMT+02:00 André Rømcke : > > > > On Sep 2,

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Silvio Marijić
>From point of immutability of object, there is no difference if property is defined or not, so you are correct, last line in your code will throw an error. 2016-09-02 11:06 GMT+02:00 Mathieu Rochette : > thank you for the clarification, more questions inline :) > > > On

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Mathieu Rochette
thank you for the clarification, more questions inline :) On 09/02/2016 04:23 AM, Michał Brzuchalski wrote: > Firstly, thanks for your interest. > My answers are inline. > > 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > >> >> On 09/01/2016 09:12 PM, Fleshgrinder wrote:

Re: [PHP-DEV] RFC - Immutable classes

2016-09-02 Thread Silvio Marijić
Hi Fleshgrinder, Since Michal answered most of the questions, I'll just add some notes. Initially I added restrictions to abstract classes, but I did think about that over the last couple of days and couldn't find any concrete reason for that restriction, so I think I'm going to remove that. As

Re: [PHP-DEV] RFC - Immutable classes

2016-09-01 Thread Michał Brzuchalski
Firstly, thanks for your interest. My answers are inline. 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > > > On 09/01/2016 09:12 PM, Fleshgrinder wrote: > > On 9/1/2016 3:49 PM, Silvio Marijić wrote: > >> Hi Andre, > >> > >> Here is RFC

Re: [PHP-DEV] RFC - Immutable classes

2016-09-01 Thread Mathieu Rochette
On 09/01/2016 09:12 PM, Fleshgrinder wrote: > On 9/1/2016 3:49 PM, Silvio Marijić wrote: >> Hi Andre, >> >> Here is RFC https://wiki.php.net/rfc/immutability and you have link to >> implementation github. Any suggestions and feedback are more then welcome. >> >> Best, >> Silvio >> > Hi Silvio, >

Re: [PHP-DEV] RFC - Immutable classes

2016-09-01 Thread Fleshgrinder
On 9/1/2016 3:49 PM, Silvio Marijić wrote: > Hi Andre, > > Here is RFC https://wiki.php.net/rfc/immutability and you have link to > implementation github. Any suggestions and feedback are more then welcome. > > Best, > Silvio > Hi Silvio, very nice work you guys did here! :) Abstract classes

Re: [PHP-DEV] RFC - Immutable classes

2016-09-01 Thread Silvio Marijić
Hi Andre, Here is RFC https://wiki.php.net/rfc/immutability and you have link to implementation github. Any suggestions and feedback are more then welcome. Best, Silvio 2016-09-01 15:43 GMT+02:00 André Rømcke : > > > > On Aug 8, 2016, at 19:19 , Michał Brzuchalski

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Michał Brzuchalski
@Fleshgrinder thanks, my knowledge of C allowed me to implement some features experimentally. When problem occurs then I'll find any needed help because I think this feature is needed. Personally I don't have wiki karma so help in writing RFC if you have karma could help us very much. 2016-08-08

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
@Fleshgrinder, Thanks, every help is welcome. 2016-08-08 18:44 GMT+02:00 Fleshgrinder : > On 8/8/2016 5:00 PM, Silvio Marijić wrote: > > 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

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Fleshgrinder
On 8/8/2016 5:00 PM, Silvio Marijić wrote: > 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 : > >> It is great to

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
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 : > It is great to hear somone is interested so why not. My lately discussion >

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Michał Brzuchalski
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

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
@Michal Would you consider cooperating on implementing immutable and sealed modifiers? 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski : > @Silvio I've tried to implement final https://github.com/php/ > php-src/compare/master...brzuchal:final-properties but haven't found

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Michał Brzuchalski
@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.

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
@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 : > > 2016-08-08 14:47 GMT+02:00 S.A.N : > >> May be better to do as immutable

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Michał Brzuchalski
2016-08-08 14:47 GMT+02:00 S.A.N : > 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

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread S.A.N
May be better to do as immutable arrays? const EmailObject = new Email; It will be a super global immutable instance of Email. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread S.A.N
May be better to do as immutable arrays? const = new Email; it will be a super global immutable instance of Email. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Michał Brzuchalski
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=146005058530881=2 Have you also read about Immutable modifier from last year? http://marc.info/?t=14476653941=1=2 it's exactly about immutable

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
Btw, I was not aware that there was already conversation on immutable classes. 2016-08-08 14:31 GMT+02:00 Silvio Marijić : > 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

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
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 : > Hi

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Michał Brzuchalski
Hi Silvio, Look into my talk about final properties https://marc.info/? t=14597925583=1=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

[PHP-DEV] RFC - Immutable classes

2016-08-08 Thread Silvio Marijić
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: public