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
