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.
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/
>
