Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63363
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: <9570D903A3BECE4092E924C2985CE485612B53B2@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local>
 <5073328D.5000002@gmail.com> <50735165.8010703@aaronholmes.net>
 <CAEPJdu=pRSDRD68t3o7XVbWRo-FvA07Wr+bzM_bwOXkwfiMxng@mail.gmail.com>
 <CACxA8bkF0EHDs3As=kMcg-BahRfBK6A5i7B9TdRc_SweCsv23A@mail.gmail.com>
 <9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local>
 <CACxA8b=wbHN_mRomH25Jr+i9BeTzj=VTGfPe_T8igjzCsMNn_Q@mail.gmail.com>
 <760ab4f994a78a846cf86aafda71e0e2@mohiva.com> <CALtuQzAH-=ePssPi-yUcXghpUhO6jOH4oDhDtPEFVj9bRf1VLA@mail.gmail.com>
 <9570D903A3BECE4092E924C2985CE485612B4EFE@MBX202.domain.local>
 <9570D903A3BECE4092E924C2985CE485612B526F@MBX202.domain.local>
 <CAPaKmR=hNUegsH1xkqNv=rRCTq4jZ+dcvk3L=DPJ7pkrTP0TNA@mail.gmail.com> <9570D903A3BECE4092E924C2985CE485612B53B2@MBX202.domain.local>
Date: Fri, 12 Oct 2012 10:29:33 +0200
Message-ID: <CAPaKmR=fk5vrxU5n_E_Oc3Pt4q2w1f8v+U=ARLiWR1GD+N7g4g@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec54d4d8e00b72904cbd87efe
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: amaury@amaury.net (Amaury Bouchard)

--bcaec54d4d8e00b72904cbd87efe
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

2012/10/12 Clint Priest <cpriest@zerocue.com>

>  I guess I didn=92t see any other support for it from others
>

Well, I get some bad replies (mainly from Andrew), but good ones too. Some
people (like Matthew) said it was an elegant syntax...



>  and it is a subset of what the RFC I am proposing would encompass
>

Yes it's true, my proposal was focusing on a subset of your RFC. But this
subset is - from my experience - the main usage of accessors.
More, both can work together: My syntax could be used to define the
visibility of reading and writing access, while yours is perfect to add
processing on these accesses.



> did I miss something with your original email?
>

I don't know. It's a matter of choice. I prefer to write:
  public:protected $a;
  protected:const $b;

Rather than:
  public $a {
    protected set;
  }
  protected read-only $b;


I saw you removed your new keywords. I think it's a good thing, because
"const" was already here (no need for "read-only").


As I said, both syntaxes can work together. For example:
  public:protected $a {
    get() { return ($this->_prefix . $this->_a); }
    set($val) { $this->_a =3D substr($val, 1); }
  }

The visibility is defined first (how I can use this property?), and then
the code is available if needed (how does it work?). It's the same logic
than when you write "private static function foo() { ... }".


Maybe I'm the only one thinking we can imagine an elegant and
understandable syntax that doesn't need to mimic what C# does. But still.
 :-)

--bcaec54d4d8e00b72904cbd87efe--