Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61251
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: <CAL9B3uzbHTrpTJH=wLXyFXDMzHZCXizmsXUu9+RYtzErL4uL0A@mail.gmail.com>
References: <CAPaKmRmn+L081722PHdzJFEO4wRyGTixacLZ38FTyBr-s8Up3w@mail.gmail.com>
 <CAL9B3uzbHTrpTJH=wLXyFXDMzHZCXizmsXUu9+RYtzErL4uL0A@mail.gmail.com>
Date: Sun, 15 Jul 2012 20:13:17 +0200
Message-ID: <CAPaKmRkRJ7u6+Q7ZEyb_LU4-+g8OGWYVpj+69O-Rsnh+qG0dow@mail.gmail.com>
To: Brandon Wamboldt <brandon.wamboldt@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04446ab3b6463204c4e245fc
Subject: Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
From: amaury@amaury.net (Amaury Bouchard)

--f46d04446ab3b6463204c4e245fc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/7/15 Brandon Wamboldt <brandon.wamboldt@gmail.com>

> This seems pretty useful, but could technically be accomplished using the
> get/set syntax already proposed. Obviously this is a cleaner implementati=
on
> however.


As I said, the get/set syntax RFC propose a "read-only" and a "write-only"
keywords.
For example, it will not allow you to have an attribute readable only by
descendant classes (and by the current class, of course), and at the same
time only writable by the current class.

PHP is an object-oriented language with public/protected private
visibility. Visibility conveys meanings, and we shouldn't loose these
meanings when we add new functionalities.

Once again, the purpose of the get/set syntax RFC is to define getters and
setters directly where attributes are defined. Attributes' visibility is a
distinct question, which deserve a distinct answer (even if there is some
obvious connections).


On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard <amaury@amaury.net> wrote=
:
>
>> 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, bu=
t
>> every line of code should be useful, not a workaround.
>> 2. You ended with 2 syntaxes; $obj->attr when the attribute is public, b=
ut
>> $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 woul=
d
>> 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 precis=
e
>> 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
>>
>
>
>
> --
> *Brandon Wamboldt*
> Programmer / Web Developer
>
> StackOverflow Careers Profile<http://careers.stackoverflow.com/brandonwam=
boldt>- GitHub
> Profile <https://github.com/brandonwamboldt> - LinkedIn<https://github.co=
m/brandonwamboldt> -
> My Blog <http://brandonwamboldt.ca/>
>
>

--f46d04446ab3b6463204c4e245fc--