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

[Denis Portnov]

08.10.2012 15:52, Clint Priest пишет:

 public $Hours {
 get { return $this-Seconds / 3600; }
 set { $this-Seconds = $value; }
 issethttp://www.php.net/isset  { return 
issethttp://www.php.net/isset($this-Seconds); }
 unsethttp://www.php.net/unset  { 
unsethttp://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:


- variable for value has the same name as property
public $Hours {
set { $this-Seconds = $Hours * 3600; }
}

- magic constant
public $Hours {
set { $this-Seconds = __VALUE__ * 3600; }
}

- 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(); }

}

- or at least have it in same format as superglobals
public $Hours {
set { $this-Seconds = $_VALUE * 3600; }
}

What do you think?

Thanks
Denis

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Denis Portnov]

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php