> On 24 Oct 2014, at 10:29, Jordi Boggiano <j.boggi...@seld.be> wrote: > > Thanks for the work (again). It's an interesting small idea but I'd much > prefer revisiting the original getter/setter RFC [1] which had a majority but > just fell short of the 66% mark. > > This RFC only implements parts of the getter/setter functionality (readonly > properties) but it does not address the fact that sometimes you want to add > logic to a setter or a getter and if you don't have language level > getters/setters you end up having to change the interface of the object from > a public property to a getFoo/setFoo pair. > > This leads to everyone having getFoo/setFoo by default just to avoid > interface changes or mixed interfaces of public properties and setFoo.
> > On 24 Oct 2014, at 10:34, Pierre Joye <pierre....@gmail.com> wrote: > > As much i really like the idea to have better properties management in > PHP I see this RFC as an attempt to solve only part of the problem > while dropping most of the other ideas implemented in the past RFCs. > My take on that is that some will vote no, or won't like the idea of > adding anything in this area. Making compromises and implement partial > solutions will only delay the implementation of the complete solution. > > Many of us agree that __get/__set is a pain to deal with.The need of > readonly, writeonly or properties with some logic to define or get a > value is a lond due need. Many other languages support that out of the > box since long already. Past RFCs, like the c# one, proposed that. I > would rather focus on trying to find an acceptable syntax and > implementation instead of doing baby steps like that. Baby steps work > very well for scalar type hinting, solving one issue after another, > etc. But for properties we are at the risk of hainvg a serie of > separate RFCs solving the properties management problems in different > ways bringing even more troubles and inconsistencies. I think I might be misunderstood, here. While getters and setters can do this, and I’m very much in favour of also reviving a simplified version of the getter/setter RFC (previous one was way too complex), I don’t see this as partly implementing them/baby steps/etc. I fact, I think readonly properties could work together with getters/setters. I don't like using property getters and setters to control whether a property can be written to or read from. I think they're the wrong solution for that - why have a virtual property with boilerplate restricted visibility accessors and mutators that get/set a hidden private property, with their associated performance penalties, when you can just make a real property that can't be read by outsiders? I think getters and setters are useful and I probably will try to revive them too sometime soon, but I think they’re actually the wrong tool for this specific job. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
