Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Sender: amaury.bouchard@gmail.com
In-Reply-To: <2F.31.18983.220E9005@pb1.pair.com>
References: <CAPaKmRmn+L081722PHdzJFEO4wRyGTixacLZ38FTyBr-s8Up3w@mail.gmail.com>
 <CAF+90c-yQe4Hjh=1KUAhN0XFkSp1OXevcvuHXiBJ2Y0isU=QeQ@mail.gmail.com>
 <CAPaKmR=rveMOaGXWjx=9s2-fU86BRe90yScwbd60hJN+-g6c3w@mail.gmail.com>
 <CAN+gjSfEt=24WvRxzEVu250U-Qm3kv1-j=qeQ7+819+oBP62gA@mail.gmail.com>
 <CAPaKmRkoCiwpFfdr9QMF-EhJ_BpuxsVCFqkV2rxvXZFt36GLYg@mail.gmail.com> <2F.31.18983.220E9005@pb1.pair.com>
Date: Sat, 21 Jul 2012 13:32:57 +0200
Message-ID: <CAPaKmRkT33s0ePhd6o6i_aVoAw0AUz+7dW48AdUAmFt2Ljb5qg@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f83a73503ac9304c5556107
Subject: Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
From: amaury@amaury.net (Amaury Bouchard)

--e89a8f83a73503ac9304c5556107
Content-Type: text/plain; charset=ISO-8859-1

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 <weierophinney@php.net>

> On 2012-07-16, Amaury Bouchard <amaury@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 <ajfweb@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 <amaury@amaury.net> wrote:
> >> > 2012/7/16 Nikita Popov <nikita.ppv@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            | matthew@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
>
>

--e89a8f83a73503ac9304c5556107--