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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
