This seems pretty useful, but could technically be accomplished using the
get/set syntax already proposed. Obviously this is a cleaner implementation
however.
On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard <ama...@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, 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 "«" . $this->str . "»"; }
> set { $this->str = trim($value, "«»"); }
> }
> }
>
> 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
>
--
*Brandon Wamboldt*
Programmer / Web Developer
StackOverflow Careers
Profile<http://careers.stackoverflow.com/brandonwamboldt>- GitHub
Profile <https://github.com/brandonwamboldt> -
LinkedIn<https://github.com/brandonwamboldt> -
My Blog <http://brandonwamboldt.ca/>
