Thank you Matthew. I had the feeling that my proposal was dismissed a bit quickly by some people, while I think it's how object-oriented languages should handle attributes' visibility. I still think it's very simple and elegant, and more coherent in some situations (those situations targeted by the proposal).
I would like everybody give 5 minutes to this idea [1] :-) [1] : http://37signals.com/svn/posts/3124-give-it-five-minutes 2012/7/21 Matthew Weier O'Phinney <weierophin...@php.net> > On 2012-07-16, Amaury Bouchard <ama...@amaury.net> wrote: > > --f46d0446312cc5e06104c4f42161 > > Content-Type: text/plain; charset=ISO-8859-1 > > > > My point is not to add two ways to do the same thing. > > What I'm humbly suggesting to do is to keep the core idea of the > > existing RFC (make things easier when you have to write > > getters/setters), and think about another syntax for managing reading > > and writing visibilities. > > My first impression, being familiar with the other proposal, was that > this looked like duplication. However, on looking at the examples, I > have to admit that I really like the approach -- in many cases, it > obviates the need for a getter entirely. It would help dry up a lot of > code, reduce the number of method calls overall, and still enforce > internal logic when setting the value in the first place. > > I like it; it feels elegant. > > > > 2012/7/16 Andrew Faulds <ajf...@googlemail.com> > > > >> How much syntactic sugar do we really need? Why add two ways to do > >> something? > >> > >> On 16 July 2012 16:24, Amaury Bouchard <ama...@amaury.net> wrote: > >> > 2012/7/16 Nikita Popov <nikita....@gmail.com> > >> > > >> >> I'm not sure I really understand what this adds over the existing > >> >> getter/setter proposal. read-only and write-only should cover the > most > >> >> common cases. If you do need visibility control, it is possible too: > >> >> > >> >> public $property { > >> >> get { ... } > >> >> protected set { ... } > >> >> } > >> >> > >> >> So what does this proposal add to it? > >> >> > >> >> > >> > Yes, but only if you have to write an accessor. > >> > If you just want an attribute that is: > >> > - readable from everywhere > >> > - writable from the current class only > >> > > >> > With my syntax: > >> > public:private $a; (read it aloud "public reading, private > writing") > >> > > >> > With the existing RFC: > >> > public $a { > >> > private set { $this->a = $value; } > >> > } > >> > > >> > Which one is better? Why should I write code for that? > >> > > >> > If you read the existing RFC, you'll see that all examples involve a > >> > specific case: when you have a "fake" attribute, which manipulates > date > >> > stored in other attributes. The given example is an $Hours attributes, > >> > which is calculated from the private $Seconds attribute. > >> > Again, it could be very useful. But it doesn't work all the time. > >> > >> > >> > >> -- > >> Andrew Faulds (AJF) > >> http://ajf.me/ > >> > > > > --f46d0446312cc5e06104c4f42161-- > > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
