On 30 November 2010 12:48, <presid...@basnetworks.net> wrote:
> Hi Richard,
>
>
>
>> I'd really like this feature to be part of PHP.
>>
>> I don't particularly like the use of what looks like a closure for the
>> set/get.
>
> While it looks like a closure, it may not necessarily be one. What I have
> presented in my RFC is a syntax, but I make little assumption about how it
> would be implemented, as that would be out stepping my expertise.
>
> In C#, when a property gets compiled it is actually turned into two normal
> class methods in a special namespace. Looking at a compiled C# library
> with reflector will reveal this underlying implementation. So when a call
> to a property is compiled in C#, it is simple replaced with a call to a
> method. The properties themselves are nothing more than syntactic sugar.
>
> Since PHP is interpreted instead of compiled, this may not be an ideal
> solution, but I couldn't guess as to what would be a better method.
> Preferably something that re-uses the existing class method
> interpretation.
>
>
>> I used to code in Delphi and I always like the way in which their
>> properties were defined.
>>
>> Essentially, the setter and getter are normal methods which are cherry
>> picked for a property [1].
>>
>> <?php
>> class TimePeriod
>> {
>> protected $seconds;
>>
>> public property Hours read getHours write setHours;
>>
>> protected function getHours()
>> {
>> return $this->seconds / 3600;
>> }
>>
>> protected function setHours()
>> {
>> $this->seconds = $value * 3600;
>> }
>>
>> // This property is read-only
>> public property Minutes read getMinutes;
>>
>> protected function getMinutes()
>> {
>> return $this->seconds / 60;
>> }
>>
>> public property Milliseconds read getMilliseconds write
>> setMilliseconds;
>>
>> public function getMilliseconds()
>> {
>> // This method is public
>> return $this->seconds * 60;
>> }
>>
>> protected function setMilliseconds()
>> {
>> // This method is protected
>> $this->seconds = $value * 3600;
>> }
>> }
>>
>> For me, the advantage here is that I can independently the methods
>> from the property. If I want to force a subclass to implement a
>> setter/getter, then I can abstract the function in the base class.
>> Sure, some may say that I should be using an interface. I disagree as
>> I probably don't want the methods to be public. Protected or even
>> private and/or final.
>
> In the syntax I provided in my RFC, it is certainly possible to define a
> property with only a get or only a set method (these are implicit
> read-only and write-only properties). Furthermore, it is also possible to
> set the visibility of the get and set methods individually, as well as
> making either one final, static or (and I forgot to mention this in the
> RFC) abstract. But the advantage of my syntax, is not only can these
> things be set individually, but they can also be set just once for the
> pair, by specifying them on the property itself. This makes for cleaner
> and more readable code.
>
> My syntax also gives several other advantages over the delphi syntax. It
> is more logical, as it makes the property look more like a class variable
> than a class method. This makes sense because you call it like a
> variable. Additionally, because the get/set methods need to be contained
> within the body of the property definition, you immediately know if a
> property has both a get and a set method at a quick glance - you do not
> have to hunt through the class to see if there is another definition
> somewhere else.
>
>
>> The classic example is one of shapes. Every shape has a public $area
>> property, but the value would be provided by an abstract protected
>> TShape::getArea(); method. I can also finalise them, so, for example,
>> a triangle shape could have a final protected getArea() method and all
>> sub classes of triangles (scalene, isosceles, equilateral) would not
>> implement their own getArea() method.
>
> This is possible with the syntax I provided. I would suggest reading more
> about the C# syntax, which my suggested syntax is based off of, as it will
> explain all of your questions.
>
> http://msdn.microsoft.com/en-us/library/x9fsa0sw%28VS.80%29.aspx
>
> - Dennis
>
>
Thanks for your reply.
Fundamentally, a big +1 from my little voice on having setters/getters in PHP.
The issue of documentation is probably that the documentation tools
would have to adapt. As things stand PHPDoc doesn't support
namespaces, so setters/getters would just be added to the WIBNI list.
With regard to the value supplied to the set method, would it make
more sense for PHP to be ...
set($value) { $this->seconds = $value * 3600; }
or
set { $this->seconds = __SETVALUE__ * 3600; }
Having $value without a clear indication of where it comes from
doesn't read quite right.
$value is way to generic to be magically created. __SETVALUE__ (or
__SOMETHINGELSE__) is clear in this regard.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
