Hi Levi, Thank you very much for your feedback! I'll try to answer some of your concerns.
Chiming in to express my disappointment that `final` wasn't a voting choice. > When I started to draft the RFC, I realized that a final property modifier that I wanted to propose would be pretty much inconsistent with final's current behaviour (since it currently controls inheritance), that's why we shouldn't copy from Java in this case. Now, readonly is the most popular choice in the vote - which directly comes from C#. - It doesn't support default values, and doesn't defend that choice > well in my opinion. > I wouldn't have thought before that this omission would be a double edged sword.. :) But I admit, I didn't really provide a well-expressed reasoning about the choice in the RFC. That was a fault. However, we talked about the decision quite a lot in the very end of the discussion thread so you might find some answers there if you are curious about more info. > - I think clone should be able to change the value. It's similar to > a constructor, and in fact I'd call it a "copy constructor." > I agree, it would be perfect if clone worked smoothly. However, my decision was to cut this aspect off from the current proposal since it's not an absolute prerequisite of "write-once" properties in my opinion. Plus, I wanted to avoid the situation when the RFC grows so big that we miss finer details out from the discussion, or when the whole feature gets rejected because a smaller detail has the wrong syntax/behaviour... Now, it seems that the whole feature can get rejected because some (IMO less important) decisions were postponed. That's Catch-22? Just one more note about this topic: clone + final doesn't work well together even in Java ( https://en.wikipedia.org/wiki/Clone_(Java_method)#clone()_and_final_fields), so it's not a kind of a problem that other languages could easily overcome. In turn, I would absolutely like to offer a more ergonomic solution for PHP as soon as possible. Please, have a look at my previous response to Nicolas where I showed the two alternatives that already came up. :) Any comments are welcome! > - The property type is mandatory. I am less certain about this, but > do not like it. > Yes, I see your point. Because of the limitations of the current type system, we had to choose: we either leave untyped properties out of the game, or start to treat them as if they had the mixed type (so a readonly $foo property would be equivalent to readonly mixed $foo). It's just the smaller problem with the latter solution that the mixed type only has a draft RFC (where the debate was mainly about if it should contain void or null...), but in my opinion, the implicit type conversion would be a mistake. This modifier shouldn't change the initialization rules of the property. At least this is what I think now, and that's why we rather chose the tradeoff to eliminate untyped properties. > I do appreciate the RFC, but think it needs a bit more work. > I also agree that my proposal couldn't give a definitive answer to all the possible questions that came up. But we - those ones who took part in the discussion - basically agreed that the feature is useful in spite of these unknowns. That's why we decided that the proposal should only keep the most important things, and carve off the rest - what's controversial or unknown yet (e.g. default values or "fixing" cloning). The most advantageous consequence of being this conservative is that we have more time (thus we can get more feedback/freedom) until we fill in the missing holes of the feature. So we made the responsible choice by postponing not clear/controversial decisions (e.g. how to treat non-typed properties) instead of trying to immediately guess the use-cases or to find workarounds. Since it's much-much easier to add support for a new thing than to revert existing rules, I believe we made a good decision. I think something similar happened when the parameter type system was extended with scalar, then nullable, and finally with the void type, or when parameter covariance initially only supported omitting the type and 2 releases later your RFC made covariance and contravariance much more complete. I hope I could give explanations to you why the RFC became what it is now, and what our thought process was. Cheers: Máté
