RFC Proposal - Attributes read/write visibility View as Markdown

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 implementation
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).

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 Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub
Profile https://github.com/brandonwamboldt - LinkedInhttps://github.com/brandonwamboldt -
My Blog <http://brandonwamboldt.ca/

An ugly, confusion-causing syntax.

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.

I'm not sure I really understand what this adds over the existing
getter/setter proposal. read-only and write-only should cover the most
common cases. If you do need visibility control, it is possible too:

public $property {
get { ... }
protected set { ... }
}

So what does this proposal add to it?

Nikita

--

--
Andrew Faulds (AJF)
http://ajf.me/

2012/7/16 Nikita Popov nikita.ppv@gmail.com

I'm not sure I really understand what this adds over the existing
getter/setter proposal. read-only and write-only should cover the most
common cases. If you do need visibility control, it is possible too:

public $property {
get { ... }
protected set { ... }
}

So what does this proposal add to it?

Yes, but only if you have to write an accessor.
If you just want an attribute that is:

• readable from everywhere
• writable from the current class only

With my syntax:
public:private $a; (read it aloud "public reading, private writing")

With the existing RFC:
public $a {
private set { $this->a = $value; }
}

Which one is better? Why should I write code for that?

If you read the existing RFC, you'll see that all examples involve a
specific case: when you have a "fake" attribute, which manipulates date
stored in other attributes. The given example is an $Hours attributes,
which is calculated from the private $Seconds attribute.
Again, it could be very useful. But it doesn't work all the time.