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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

(Let me suggest an idea irrelevant. Sorry...) The performance of getters is critical. For me the best solution would be a new keyword, equivalent to a "var" without write access from outside the class: class TimePeriod { *property* $Hours = 1; public function setHours($h) {

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

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

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

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

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

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

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

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

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

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

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

> field(s) protected - this would be the equivalent of > declaring a read-only accessor that you are permitted to extend with a > write-accessor if you need to... > > > -- Forwarded message ---------- > From: Jazzer Dane > To: Leigh > Cc: Clint Priest , "int

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

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

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

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

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

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

> 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

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

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

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

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

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

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

This looks great, and essentially has everything I had hoped for! My only remaining comment is on the read-only and write-only keywords... this seems really superfluous and strange to me - the syntax (using a hyphenated keyword) and the feature itself, is way off the grid as compared to other lang

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

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

> 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

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

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

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

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

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

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

, 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

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

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

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

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

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

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

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

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

Good work Clint! Performance is probably one of the things people will complain about so it's good that your benchmark is proving that it's merely identical to the old __get() approach. What remains on your TODO list for this functionality? When are you planning to run an RFC vote on this? I thi

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

As an update, just ran some performance testing: master Cycles Direct Getter __get v1.4 @ 10/8/20121m .05s.21s .20s php 5.5.0-dev