Re: [RFC] Propety Accessors v1.1
| From: | Denis Portnov | Date: | Tue, 09 Oct 2012 02:53:25 +0000 |
| Subject: | Re: [RFC] Propety Accessors v1.1 | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63289@lists.php.net to get a copy of this message | ||
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 the original author thought to keep it the same as another well-known language (why re-invent new syntax for no reason). Well, in C# 'value' is a contextual keyword not a variable. Same as : get, set, yield. So I'd argue, copying the syntax of well-known language is not the case here.
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) { ... }
Didn't fully graps the internals yet, not that sharp in C, sorry. Is there a possibility of collision with user-defined __getHours() method?
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? I kinda share your concern for having parameterized syntax for set() only. One way out of this could be introducing new keyword complimentary to 'return' to define by what name value will be presented in local scope. Possible names whould be: keep, accept or valuepublic $Hours {
get {
return $this->seconds / 3600;
}
set {
// present value as $hours in local scope
keep $hours;
$this->seconds = $hours * 3600;
}
}
I find people's need for typehinting plausible though
Thanks
Denis