Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63282
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
MIME-Version: 1.0
Sender: amaury.bouchard@gmail.com
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local>
Date: Mon, 8 Oct 2012 15:27:26 +0200
Message-ID: <CAPaKmRkLMi_COxwdRashYarxPWhp+dz+dTVPW09PCMZ5POZ5hA@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10cde3ec7de504cb8c2ff5
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: amaury@amaury.net (Amaury Bouchard)

--047d7b10cde3ec7de504cb8c2ff5
Content-Type: text/plain; charset=ISO-8859-1

Hi,

This summer (july 15) I did another proposal, which has some connections
with yours.

For the main usage of getters/setters, my guess is that we need separate
read/write visibilities. Your RFC goes beyond that, but I think both are
complementary.
Most of the time, we write getters/setters to ensure that a private
attribute can be read but not modified (or modified only as we want to).
Your RFC is pretty powerful in some use cases. Like your example, which is
a "virtual" attribute, created from some processing. But create a new
"read-only" keyword is not a good idea for me: introduce a new keyword
should be avoided when it's not absolutely necessary, and it lacks meaning
(exact visibility information).

Correct me if I'm wrong, but your syntax is similar to the one used in C#.
Not a bad idea, but I think we can imagine for PHP somethink a little more
concise for the general usage.

My idea was to write attribute's visibility like
"read_visiblity:write_visibility $attr;"
  public:protected $foo; // public reading, protected writing
  public:private $bar; // public reading, private writing
  protected:private $aaa; // protected reading, private writing
  protected:const $bbb; // protected reading, no writing

With your RFC it will be:
  public $foo { get; protected set; }
  public $bar { get; private set; }
  protected $aaa { get; private set; }
  protected read-only $bbb;

When I did my proposal on the internals mailing-list, I got some pretty bad
feedbacks, and some very good ones.
So, maybe we can try to merge some ideas?

My patch: http://github.com/Amaury/php-src

Regards,

Amaury


2012/10/8 Clint Priest <cpriest@zerocue.com>

> It's been a while since I posted any updates about this, a few individuals
> have been asking about it privately and wanting me to get it out the door
> for PHP 5.5 release.  It's come a long way since the last time I posted
> about it.
>
> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>
> Example Usage:
>
> class TimePeriod {
>     private $Seconds = 3600;
>
>     public $Hours {
>         get { return $this->Seconds / 3600; }
>         set { $this->Seconds = $value; }
>         isset<http://www.php.net/isset> { return isset<
> http://www.php.net/isset>($this->Seconds); }
>         unset<http://www.php.net/unset> { unset<http://www.php.net/unset>($this->Seconds);
> }
>     }
> }
>
> Changes / Updates
>
> *         isset/unset accessor functions now implemented (object & static
> context, auto implementations, etc)
>
> *         static accessor now fully functional
>
> *         Reference functionality validated, tests written
>
> *         All operators have been tested, tests written
>
> *         read-only and write-only keywords: Added explanation of reasons
> for inclusion at the top of the appropriate RFC section
>
> *         Tested for speed, approaches or meets __get() speed.
>
> Internally things have changed quite a bit
>
> *         cleaned up and simplified
>
> *         had been using 4 to 5 additional fn_flag slots, now down to two
> (READ_ONLY and WRITE_ONLY)
>
> *         the automatic implementations now compiled internal php code,
> this greatly simplified that part of the code and future proofed it.
>
> The code is available at the url below and is up to date with master, all
> tests pass.
> https://github.com/cpriest/php-src
>
> I'd like to get this project wrapped up in time to make it to the 5.5
> release, only a few things remain to be completed/updated:
>
> *         Check on reflection code written prior to major changes (tests
> still pass)
>
> *         Add a few more reflection functions that were requested
>
> In total there are 79 tests for this new functionality, if there are any
> others that I have missed, please let me know.
>
> -Clint
>
>

--047d7b10cde3ec7de504cb8c2ff5--