Re: [RFC] Propety Accessors v1.1

From: 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 value
public $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

« previous php.internals (#63289) next »