Great arguments for, anyone against this being the new way? If not then I’ll begin work on this change as well. I would like to keep this discussion going so that at the end of this two week discussion period I can submit it for voting.
Jazzer, your points make a lot of sense in terms of making it clear that they are all functions, I’m all game. If it’s not difficult I may just make it compatible in both ways (auto-define $value) if parenthesized option is not specified. Flexibility is at the heart of php. -Clint From: Jazzer Dane [mailto:tbprogram...@gmail.com] Sent: Monday, 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 using $value. Even if $value internally makes sense due to something along the lines of __setHours($value) {} being equal to set {}, I think using $value without it ever being defined in the developer's code is not at all a good idea. If I see $value in the code, I'll logically look for where it was defined, and when I don't see it anywhere else in the code, things are going to very quickly get confusing. Our best option to combat this confusion is, in my eyes, putting a note in the documentation. That's not enough. A similar alternative to using $value that I'd argue would be much more sensible would be to, as Denis mentioned, use either a magic constant or a superglobal. As I mentioned previously, I would rather go with the set($value) {} syntax. Now, back to the part where I agree with you - the inconsistency wherein set has () that denote it is a method but get, isset, and unset do not. I see this inconsistency as something problematic enough to warrant a solution. We could go with the following: public $Hours { get() { ... } set($value) { ... } isset() { ... } unset() { ... } } Yes, we now have a little bit more meat on the syntax, but in this case, I don't think that it's all that bad. Here's two reasons why: 1) Adding parenthesis denotes that they are all functions - which they are! If anything, adding parenthesis to all of them makes the implementation more sensible. 2) It's only two more characters per function. On top of that, in my opinion, this syntax is not "ugly". In fact, as I just mentioned - this implementation is arguably more consistent with the rest of PHP. On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest <cpri...@zerocue.com<mailto:cpri...@zerocue.com>> wrote: 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 the original author thought to keep it the same as another well-known language (why re-invent new syntax for no reason). That being said, javascript does indeed allow it, my concern then would be would we have the parameterized syntax only for set() and not get, isset or unset? If we do have them for all of them, it's a lot of extra characters with no real need. I definitely favor 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 { ... } } Is implemented as standard functions, while they are hidden through reflection, these functions exist (as a result of the above example): public __getHours() { ... } public __setHours($value) { ... } Lastly, with regards to JavaScript style getters/setters, I don't think I've ever cared what the variable name was, I typically just do something 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<mailto:tbprogram...@gmail.com>] > Sent: Monday, October 08, 2012 5:32 PM > To: Benjamin Eberlei > Cc: Aaron Holmes; internals@lists.php.net<mailto: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 constant, which is quite nice. The > typehinting is a big plus as well. > > On Mon, Oct 8, 2012 at 3:26 PM, Benjamin Eberlei > <kont...@beberlei.de<mailto:kont...@beberlei.de>>wrote: > > > The set() one is really nice with the typehints. > > > > On Tue, Oct 9, 2012 at 12:19 AM, Aaron Holmes > > <aa...@aaronholmes.net<mailto:aa...@aaronholmes.net>> > > 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->Seconds = $value; } > > >>> isset<http://www.php.net/isset**> { return isset< > > >>> http://www.php.net/isset**>($this->Seconds); } > > >>> unset<http://www.php.net/unset**> { unset< > > >>> http://www.php.net/unset**>($this->Seconds); } > > >>> } > > >>> > > >> > > >> > > >> Hi Clint, > > >> > > >> I've noticed some magic variable '$value' is introduced. And except > > >> for superglobals I guess there is no such thing in PHP, so it looks > > >> bit puzzling to me. I'd suggest on of the following: > > >> > > >> > > >> - setter resambles setter method, wich also allows typehinting > > >> public $Hours { > > >> set ($value) { $this->Seconds = $value * 3600; } > > >> } > > >> > > >> public $Hours { > > >> set (DateTime $dateTime) { $this->Seconds = > > >> $dateTime->getTimestamp(); } > > >> } > > >> > > >> This seems like the cleanest method, in my opinion. Javascript > > >> does > > this > > > for object prototypes: > > > http://ejohn.org/blog/**javascript-getters-and-**setters/< > > http://ejohn.org/blog/javascript-getters-and-setters/> > > > > > > > > >> > > >> What do you think? > > >> > > >> Thanks > > >> Denis > > >> > > >> > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > > visit: http://www.php.net/unsub.php > > > > > > > >
