[PHP-DEV] [RFC] Propety Accessors v1.1

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-im

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

27;s <.01s difference. Depending on the run it is sometimes exactly the same performance. > -Original Message- > From: Clint Priest [mailto:cpri...@zerocue.com] > Sent: Monday, October 08, 2012 6:53 AM > To: internals@lists.php.net > Subject: [PHP-DEV] [RFC] Propety Accessors

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

rmance. > >> -Original Message- >> From: Clint Priest [mailto:cpri...@zerocue.com] >> Sent: Monday, October 08, 2012 6:53 AM >> To: internals@lists.php.net >> Subject: [PHP-DEV] [RFC] Propety Accessors v1.1 >> >> It's been a while since I posted any up

Re: [PHP-DEV] [RFC] Propety Accessors v1.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 e

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

08.10.2012 15:52, Clint Priest пишет: public $Hours { get { return $this->Seconds / 3600; } set { $this->Seconds = $value; } isset { return isset($this->Seconds); } unset { u

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10/8/12 1:07 PM, Denis Portnov wrote: 08.10.2012 15:52, Clint Priest пишет: public $Hours { get { return $this->Seconds / 3600; } set { $this->Seconds = $value; } isset { return isset($this->Seconds); }

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

The set() one is really nice with the typehints. On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes wrote: > On 10/8/12 1:07 PM, Denis Portnov wrote: > >> 08.10.2012 15:52, Clint Priest пишет: >> >>> public $Hours { >>> get { return $this->Seconds / 3600; } >>> set { $this->Sec

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

I agree. It's more consistent than the $Hours solution and we don't have to add another superglobal or magic constant, which is quite nice. The typehinting is a big plus as well. On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei wrote: > The set() one is really nice with the typehints. > > On Tue,

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

tober 08, 2012 5:32 PM > To: Benjamin Eberlei > Cc: Aaron Holmes; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > I agree. > It's more consistent than the $Hours solution and we don't have to add > another superglobal or magic co

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

09.10.2012 5:10, Clint Priest пишет: Seems a fair amount of people would like it with a definable parameter name, though the original RFC I based mine off of is more than 4 years old (mine is over a year old already). The $value is precisely chosen because it is exactly the way C# operates and

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

ng > like: > > set blah(x) { ... } <-- x is fairly irrelevant and similarly the use of > $value is fairly irrelevant. Thoughts? > > > -Original Message- > > From: Jazzer Dane [mailto:tbprogram...@gmail.com] > > Sent: Monday, October 08, 2012 5:32 PM > >

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

, October 08, 2012 10:08 PM To: Clint Priest Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 While I understand your concern with set being the only keyword using (), and even agree it's a bit problematic, I see a big problem with

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Dane [mailto:tbprogram...@gmail.com] Sent: Tuesday, October 09, 2012 5:08 AM To: Clint Priest Cc: internals@lists.php.net; Aaron Holmes; Benjamin Eberlei Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 While I understand your concern with set being the only keyword using (), and even agree it&#x

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Dane [mailto:tbprogram...@gmail.com] > Sent: Monday, October 08, 2012 5:32 PM > To: Benjamin Eberlei > Cc: Aaron Holmes; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > I agree. > It's more consistent than the $Hours solution and we don't

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

or set($value) over a magic $Hours for the $Hours >>> property, but I personally see no problem with the $value, it's not magic >>> it's a locally defined variable. >>> >>> Internally, this: >>> public $Hours { >>> get { ... } >>> set

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

I personally see no problem with the $value, it's not magic >>> it's a locally defined variable. >>> >>> Internally, this: >>>public $Hours { >>> get { ... } >>> set { ... } >>>} >>> >>> Is

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest wrote: > 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

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi, On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov wrote: > On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest wrote: >> 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'

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

> What concerns me with the current implementation is that it leaks many > implementation details, in particular the fact that the accessors are > implemented as *real* __getXYZ methods and automatic implementations > also use *real* $__XYZ properties. Further to this, take the following example.

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

l.com] On Behalf Of Etienne Kneuss Sent: Tuesday, October 09, 2012 8:15 AM To: Nikita Popov Cc: Clint Priest; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 Hi, On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov wrote: > On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest wro

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented public $property { set { $this->property = ($this->property*2)+$value } get; } How do I reference the property being set from within the function? The way I have done it in the example will cause recursion? How can I ass

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

to declare it explicitly everywhere. Just my two cents... ---- Subject: [PHP-DEV] [RFC] Propety Accessors v1.1 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

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Mon, 2012-10-08 at 11:52 +, Clint Priest wrote: > 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. > >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

I think Leigh brings up some important flaws to in the current RFC. What Leigh is asking for does not appear to be possible, and in my opinion, it should be. I also agree with Rasmus, to a certain extent. By putting only a getter/setter, the developer essentially sets the property as read or write

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 09/10/12 19:20, Jazzer Dane wrote: - "If we ever get return type hinting/checks then we needn't consider how the syntax has to look" From what I know, this isn't planned for PHP 5.5 and any proposals for it have been largely ignored. Return type hinting won't help when setting either, although

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Wow, I'm surprised by all the talk about this RFC this time around. I posted this numerous times in the past trying to elicit feedback and got little to none, so I took the time to write it as I thought it should be written. Some of these things will take considerable effort to fix/correct/cha

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi Clint, In order to achieve read-only and write-only, we could do something similar to this: /* Explicitly read-only, sub-classes may redefine the getter but may not define a setter */ public $Hours { get() { ... } final private set() {} } This would make the additional keyword superfl

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10 October 2012 01:16, Johannes Schlüter wrote: > Up until now reflection is leaky and is telling the truth. We should > either keep that or completely clean up reflection. Reflection should always tell the truth, or there is no point in it. On 10 October 2012 04:28, David Muir wrote: > That

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10 October 2012 04:51, Clint Priest wrote: > Wow, I'm surprised by all the talk about this RFC this time around. I > posted this numerous times in the past trying to elicit feedback and got > little to none, so I took the time to write it as I thought it should be > written. Some of these thi

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10 October 2012 08:46, Bernhard Schussek wrote: > Second, I'd like to throw in the idea of array accessors. I mentioned > this before, but did not get any response. > > public $Addresses { > offsetSet($offset, $value) { ... } > offsetGet() { ... } > offsetUnset($offset) { ... } >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Here's my feedback on some current outstanding issues/suggestions: 1) Default value: I think having functionality for a default value is necessary, but I'm also thinking it may already be implementable within the current syntax. > class Test { > private $seconds; > public $hours { >

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> On 10 October 2012 01:16, Johannes Schlüter wrote: > > Up until now reflection is leaky and is telling the truth. We should > > either keep that or completely clean up reflection. > > Reflection should always tell the truth, or there is no point in it. > Unfortunately the "truth" here is subj

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> > Second, I'd like to throw in the idea of array accessors. I mentioned > > this before, but did not get any response. > > > > public $Addresses { > > offsetSet($offset, $value) { ... } > > offsetGet() { ... } > > offsetUnset($offset) { ... } > > offsetExists($offset) { ... } > >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

2012/10/10 Clint Priest : > While I agree it would be a "nice to have" it would also be un-necessary. > There are already ways to do precisely what is desired here by way of > ArrayAccess. > > class Addresses implements ArrayAccess { > offsetSet($offset, $value) { ... } > offsetG

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> >> What concerns me with the current implementation is that it leaks > >> many implementation details, in particular the fact that the > >> accessors are implemented as *real* __getXYZ methods and automatic > >> implementations also use *real* $__XYZ properties. > > > I don't particularly see th

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

On Wed, 2012-10-10 at 11:53 +, Clint Priest wrote: > > On 10 October 2012 01:16, Johannes Schlüter wrote: > > > Up until now reflection is leaky and is telling the truth. We should > > > either keep that or completely clean up reflection. > > > > Reflection should always tell the truth, or th

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest wrote: > I'm not even sure that automatic backing fields are even desired, I never > felt the need to have them in C# and the only reason they were included is > because they were a part of Dennis's original proposal. Eliminating them > would eliminat

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

> On Wed, Oct 10, 2012 at 5:51 AM, Clint Priest wrote: > > I'm not even sure that automatic backing fields are even desired, I > > never felt the need to have them in C# and the only reason they were > > included is because they were a part of Dennis's original proposal. > > Eliminating them would

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 8, 2012, at 10:07 PM, Denis Portnov wrote: > 08.10.2012 15:52, Clint Priest пишет: >> public $Hours { >> get { return $this->Seconds / 3600; } >> set { $this->Seconds = $value; } >> isset { return >> isset($t

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

m: Jazzer Dane To: Leigh Cc: Clint Priest , "internals@lists.php.net" < internals@lists.php.net> Date: Tue, 9 Oct 2012 19:33:20 -0700 Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > class A { > > public $seconds = 3600; > > > > public $hours { > >

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > > There's no way to stop the developer from doing that without read-only. > > Yes, there is - I don't even know why would write it that way - doesn't seem > to make much sense. > > What you pr

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Okay, I would like this to be the last time there are revisions to this RFC. To sum up the last few days of conversations, I have these down as points of contention: 1. Accessor functions should not be present on the object and callable directly, for example, $o->__getHours() should not be a

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Wed, Oct 10, 2012 at 6:35 PM, Clint Priest wrote: > I will come up with some way for people to vote on the issues at hand and > we can cast our votes and be done with it, then I will finish the project > and get it out the door. > > -Clint I very much appreciate your work in this area, Clint,

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Just a couple of quick remarks. Clint wrote: > I'm not even sure that automatic backing fields are even desired, I never felt the need to have them in C# and the only reason they were included is because they were a part of Dennis's original proposal. Automatic backing fields are indeed necessar

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 10/10/12 21:41, Jazzer Dane wrote: Here's my feedback on some current outstanding issues/suggestions: 1) Default value: I think having functionality for a default value is necessary, but I'm also thinking it may already be implementable within the current syntax. class Test { private $

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

This all sounds about right. In regards to #4 - read-only/write-only: I think that, from a "pretty syntax" point of view, private final set() {} and private final get() {} are definitely our best bets. But... from a logical point of view, I prefer read-only/write-only. private final get() {} is t

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

the few modern languages that does not have such a feature. > -Original Message- > From: Levi Morrison [mailto:morrison.l...@gmail.com] > Sent: Wednesday, October 10, 2012 8:27 PM > To: Clint Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Acces

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

Wednesday, October 10, 2012 9:18 PM To: Clint Priest Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 This all sounds about right. In regards to #4 - read-only/write-only: I think that, from a "pretty syntax" point of view, private final set() {} and privat

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 11, 2012 5:00 AM, "Clint Priest" wrote: > > Why is everyone so dead set against read-only and write-only? > > I could not disagree more with you on what is "pretty" and "readable". > > To me: > > public read-only $hours { > get { ... } > } > > Is infinitely more readable and

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

What about private final set($value) { } tells you that it's read only? There is a setter. From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, October 11, 2012 12:05 AM To: Clint Priest Cc: PHP internals; Jazzer Dane Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1 On O

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

implies that it can be “set” within the right context > (internally to the class), which is precisely the opposite of what is > desired (read only).**** > > ** ** > > *From:* Jazzer Dane [mailto:tbprogram...@gmail.com] > *Sent:* Wednesday, October 10, 2012 9:18 PM > *To:* Clint Priest >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Clint Priest wrote: I certainly would not want to push through the door a low quality solution, I would never do that, but I have been working on this project myself for a year and each time I come back, having addressed the concerns of the last batch of opinions there are a whole new set of c

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Thu, Oct 11, 2012 at 2:35 AM, Clint Priest wrote: > Okay, I would like this to be the last time there are revisions to this > RFC. > > To sum up the last few days of conversations, I have these down as points > of contention: > > 1. Accessor functions should not be present on the object and c

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

the same performance. -Original Message- From: Clint Priest [mailto:cpri...@zerocue.com] Sent: Monday, October 08, 2012 6:53 AM To: internals@lists.php.net Subject: [PHP-DEV] [RFC] Propety Accessors v1.1 It's been a while since I posted any updates about this, a few individuals have

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

in php that uses hyphen in it. > > From: Jazzer Dane [mailto:tbprogram...@gmail.com] > Sent: Wednesday, October 10, 2012 9:18 PM > To: Clint Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > This all sounds about right. >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

t's really read-only. > > From: Jazzer Dane [mailto:tbprogram...@gmail.com] > Sent: Wednesday, October 10, 2012 9:18 PM > To: Clint Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > This all sounds about right. > > In regard

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

hi, On Thu, Oct 11, 2012 at 2:16 PM, Sebastian Krebs wrote: > public read-only $hours { > get { /* .. */ } > set { /* .. */ } > } that should not be possible or it will be too complicated to document or to use. Combinations of the readonly option and a setter should not be possible.

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

This would produce a compile error, cannot define set, property is read-only. > -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Thursday, October 11, 2012 7:43 AM > To: Sebastian Krebs > Cc: internals@lists.php.net > Subject: Re: [PHP-

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On 11 October 2012 12:46, Cal wrote: > For me the best solution would be a new keyword, equivalent to a "var" > without write access from outside the class: New keywords should not (will not) be introduced trivially, they can cause massive headaches with backwards compatibility breaks, and should

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

only). ** ** *From:* Jazzer Dane [mailto:tbprogram...@gmail.com] *Sent:* Wednesday, October 10, 2012 9:18 PM *To:* Clint Priest *Cc:* internals@lists.php.net *Subject:* Re: [PHP-DEV] [RFC] Propety Accessors v1.1 ** ** This all sounds about right. In regards to #4 - read-only/write-o

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

greement... Or... do ya'll want to vote on the aforementioned changes? > -Original Message- > From: Clint Priest [mailto:cpri...@zerocue.com] > Sent: Wednesday, October 10, 2012 7:36 PM > To: internals@lists.php.net > Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1 &g

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

> If there isn't anyone against the above changes, I will make the changes to > the RFC and re-present for final agreement... > > Or... do ya'll want to vote on the aforementioned changes? > >> -Original Message- >> From: Clint Priest [mailto:cpri...@zerocue.

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

anyone against the above changes, I will make the changes > to the RFC and re-present for final agreement... > > Or... do ya'll want to vote on the aforementioned changes? > > > -Original Message- > > From: Clint Priest [mailto:cpri...@zerocue.com] > > Sent:

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

> > > -Original Message- > > From: Clint Priest [mailto:cpri...@zerocue.com] > > Sent: Wednesday, October 10, 2012 7:36 PM > > To: internals@lists.php.net > > Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1 > > > > Okay, I would like this to

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

er 11, 2012 6:42 PM To: Clint Priest Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 You really don't want to even think about my idea? It's complementary on some aspects, you know. 2012/10/11 Clint Priest mailto:cpri...@zerocue.com>> Rather than

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

2012/10/12 Clint Priest > I guess I didn’t see any other support for it from others > Well, I get some bad replies (mainly from Andrew), but good ones too. Some people (like Matthew) said it was an elegant syntax... > and it is a subset of what the RFC I am proposing would encompass > Yes

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Le 12 oct. 2012 10:37, "Bernhard Schussek" a écrit : > > As I said, both syntaxes can work together. For example: > > public:protected $a { > > get() { return ($this->_prefix . $this->_a); } > > set($val) { $this->_a = substr($val, 1); } > > } > > A shortcoming of this syntax is that i

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi! > The RFC states > ReflectionClass::getMethods() will not return accessor functions > (hides implementation detail). > Up until now reflection is leaky and is telling the truth. We should > either keep that or completely clean up reflection. (mind also > get_class_methods() and

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi! > Does the PHP programmer need the "truth of underlying language > implementation details" or do they need the "truth" of what they've > defined? If the method exists, he needs to know it exists. For the rest, see below. > I would argue that if the PHP programmer has defined a property > acc

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Hi! > What remains on your TODO list for this functionality? > When are you planning to run an RFC vote on this? > > I think this would be a valuable addition to PHP 5.5. I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a *huge* feature - one of the

RE: [PHP-DEV] [RFC] Propety Accessors v1.1

AM > To: Paul Dragoonis > Cc: Clint Priest; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > Hi! > > > What remains on your TODO list for this functionality? > > When are you planning to run an RFC vote on this? > > > >

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 16, 2012 11:27 AM, "Stas Malyshev" wrote: > > Hi! > > > What remains on your TODO list for this functionality? > > When are you planning to run an RFC vote on this? > > > > I think this would be a valuable addition to PHP 5.5. > > I think we shouldn't rush with votes on this until all fine

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Stas Malyshev wrote: >What remains on your TODO list for this functionality? >When are you planning to run an RFC vote on this? > >I think this would be a valuable addition to PHP 5.5. I think we shouldn't rush with votes on this until all fine details aren't hashed out. This is a*huge* feature

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

Le 08/10/2012 14:27, Amaury Bouchard a écrit : 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; // protecte