Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61246
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
Date: Sun, 15 Jul 2012 17:46:08 +0200
Message-ID: <CAPaKmRmn+L081722PHdzJFEO4wRyGTixacLZ38FTyBr-s8Up3w@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f642fee6a042804c4e03757
Subject: RFC Proposal - Attributes read/write visibility
From: amaury@amaury.net (Amaury Bouchard)

--e89a8f642fee6a042804c4e03757
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Here is an RFC proposal about a syntax extension for PHP. The purpose is to
manage precisely the visbiliy of attributes, by separating reading and
writing access.

First of all, I know there is already an RFC about attributes ("Property
get/set syntax" [1]). Its goal is mainly different, but I'll discuss it
lower.


THE PROBLEM
In my experience, one of the major usage of getters is when you want to
have an attribute, readable (but not writable) from outside the object.
More, the attribute's visibilty is then chosen between private and
protected, depending on your inheritance design.

The result is not really satisfying:
1. You have to write getter's code. Maybe, it's just a simple return, but
every line of code should be useful, not a workaround.
2. You ended with 2 syntaxes; $obj->attr when the attribute is public, but
$obj->getAttr() when you must use a getter. It's a bit schizophrenic.


THE IDEA
I suggest to be able to separate reading visibility and writing visibility,
using a colon to separate them. If only one visibility is given, it will be
used for both reading and writing access.

For example:
class A {
    public $a;           // public reading, public writing
    public:public $b;    // the same
    public:protected $c; // public reading, protected writing
    public:private $d;   // public reading, private writing
    public:const $e;     // public reading, no writing allowed

    protected $f;           // protected reading, protected writing
    protected:protected $g; // the same
    protected:private $h;   // protected reading, private writing
    protected:const $i;     // protected reading, no writing allowed

    private $j;         // private reading, private writing
    private:private $k; // the same
    private:const $l;   // private reading, no writing allowed
}

As you can see, I think that writing access should be more restrictive than
reading access (or equivalent to it). A "private:public" visibility would
make no sense.


SOURCE CODE
I did a patch. It kinda works, but I'm still working on it (because I'm
still learning Zend Engine's internals).
The code on GitHub: https://github.com/Amaury/php-src
All advises are welcome.


PRIOR WORK
As I said before, the "Property get/set syntax" RFC is in discussion. My
proposal doesn't focus on the same goals, but they could be fully
compatible.

Thus, we would be able to write this kind of code:
class A {
    // $str has public reading and private writing,
    // and manage french quotes
    public:private $str {
        get { return "=AB" . $this->str . "=BB"; }
        set { $this->str =3D trim($value, "=AB=BB"); }
    }
}

Maybe you saw that the "Property get/set syntax" RFC has an intended syntax
for read-only and write-only attributes. From my point of view, there is a
deep and clean separation between a getter/setter syntax and an extended
visibility syntax. It shouldn't be in the same RFC.
More, the proposed "read-only" and "write-only" keywords are less precise
and powerful than what I'm suggesting.


I would be happy to discuss all that with you guys.

Best regards,

Amaury Bouchard


[1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

--e89a8f642fee6a042804c4e03757--