Re: RFC Proposal - Attributes read/write visibility
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 <[email protected]>
> On 2012-07-16, Amaury Bouchard <[email protected]> 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 <[email protected]>
> >
> >> How much syntactic sugar do we really need? Why add two ways to do
> >> something?
> >>
> >> On 16 July 2012 16:24, Amaury Bouchard <[email protected]> wrote:
> >> > 2012/7/16 Nikita Popov <[email protected]>
> >> >
> >> >> 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 | [email protected]
> 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
>
>
Thread (21 messages)