RFC: C-sharp style property get/set syntax for PHP

2010/11/29 Ángel González keisial@gmail.com:

Richard Quadling wrote:
setMilliseconds() should have $value as parameter instead of a magic name.

What about allowing this syntax to attach the property to a variable?

For instance:

<?php
class TimePeriod
{
   protected $seconds;
   protected $minutes;
   protected $hours;

   public property Seconds read $seconds write setSeconds;
   public property Minutes read $seconds write setMinutes;
   public property Hours read $seconds write setHours;

   public function setSeconds($seconds)
   {
       if ($seconds >= 0 && $seconds < 60) $this->seconds = $seconds;
   }

   public function setMinutes($minutes)
   {
       if ($minutes >= 0 && $minutes < 60) $this->minutes = $minutes;
   }

   public function setHours($hours)
   {
       if ($hours >= 0 && $hours < 24) $this->hours = $hours;
   }

}

We only want to perform checks on write, so instead of writing the trivial
getters, the property is set to the variable itself. Child classes could
reattach it to a function if needing more control.

Ouch. I messed up on the example code. Completely forget that there
was a parameter to process...

As for reading $seconds directly ...

Well.

If you think of the element that follows read as $this->xxxx, then if
the parser can handle both ...

read $seconds
read getSeconds

then yes for both.

If not, then I'd guess that the getSeconds version should be the one
we use as the value may not actually exist without some processing.

Richard.

--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

What about allowing this syntax to attach the property to a variable?

For instance:

<?php
class TimePeriod
{
protected $seconds;
protected $minutes;
protected $hours;

 public property Seconds read $seconds write setSeconds;
 public property Minutes read $seconds write setMinutes;
 public property Hours read $seconds write setHours;

 public function setSeconds($seconds)
 {
     if ($seconds>= 0&&  $seconds<  60) $this->seconds = $seconds;
 }

 public function setMinutes($minutes)
 {
     if ($minutes>= 0&&  $minutes<  60) $this->minutes = $minutes;
 }

 public function setHours($hours)
 {
     if ($hours>= 0&&  $hours<  24) $this->hours = $hours;
 }

}

We only want to perform checks on write, so instead of writing the trivial
getters, the property is set to the variable itself. Child classes could
reattach it to a function if needing more control.

Another advantage here would presumably be performance. If there's no
getter defined then the engine could simply map $foo->bar to the class
member directly (which is really fast) and not to a method, so there's
no added overhead there. That still leaves the question of what happens
with name collisions, though.

... and that makes me think that someone is sure to ask about runtime
changes to the property structure sooner or later, as we keep asking
about methods (and sort of have figured out with binding closures to
objects, if that did actually get committed), so I'll go ahead and ask
it now. :-)

--Larry Garfield

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

Nice RFC, just an idea for an alternative syntax (added to the RFC as #2):

property Hours {
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; } // The variable $value holds
the incoming value to be "set"
}

class TimePeriod
{
private $seconds;

 public [Hours] $hours1;
 public {use Hours;} $hours2;

}

If you change "property" to "class" or "trait" and "get" to "__get" you
need almost no new syntax :)

Not really. With __get() and __set(), it's entirely likely that the class into
which the trait is mixed in might override this already -- and not take into
account the properties. That would be quite a brittle solution.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Hi!

Nice RFC, just an idea for an alternative syntax (added to the RFC
as
#2):

property Hours {
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; } // The variable $value
holds
the incoming value to be "set"
}

class TimePeriod
{
private $seconds;

 public [Hours] $hours1;
 public {use Hours;} $hours2;

}

If you change "property" to "class" or "trait" and "get" to "__get"
you need almost no new syntax :)

Right, it looks the same but the subtle difference is 'property Hours'
wouldn't be registered as a class. It's just container code for get(), set()
methods that would get 'compiled' into opcodes in the class TimePeriod (the
property exists vs. searching for it in runtime). So you can think of it as
a special 'trait' that only applies to properties.

The idea behind this syntax is you can move the 'property' definition out of
the class so that you can test and re-use it somewhere else (like traits).

That might not be problem if you can define properties in traits (needs to
be explained in the RFC):
trait TimeUnits {
public property Seconds
{
get { return $this->seconds; }
set { $this->seconds = $value; }// The variable $value holds the
incoming value to be "set"
}
public property Minutes
{
get { return $this->seconds / 60; }
set { $this->seconds = $value * 60; }
}
public property Hours
{
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; }// The variable $value holds
the incoming value to be "set"
}
}

class MyTime {
uses TimeUnits;

protected $_seconds;
}

Hi Dennis!

Could you please stop trying to push the feature like it is in C#? PHP
is a different language, with absolutely different purpose and with
it's specifics - both as historically and based on it's purpose as a
WEB development language.
I admire your passion, but really, the amount of e-mails and your
stubbornness is exceeding any reasonable threshold. People are trying
to tell you that in PHP there is it's own mechanics and way hot it
works and what proposals should include. You are trying to tell us
that we need to throw away the internal workings of PHP and write a
feature witch totally breaks how the PHP and it's OOP model work.

I'm sorry if in last 10-15 emails there was any change to better
understanding the PHP, I just didn't follow any more. I'm sorry if I
offend you in any way by this e-mail, but really... I think it has to
stop. Don't push features witch are inconsistent with PHP.

Please?!

2010/12/1 Richard Quadling rquadling@gmail.com

On 1 December 2010 09:22, Stas Malyshev smalyshev@sugarcrm.com
wrote:
...

Why change the expected behavior of isset? If a property has not been
set
then isset must return false, and that includes $foo->name = NULL.

Thats simple then, when isset is invoked, call the get method, and if it
returns null then isset() returns false, but otherwise returns true.
That
was likely just a small oversight on Richard's part.

No, it was not an oversight.

Calling the getter() in response to isset() will probably result in a
change to the value of the property. For a property, isset() can and
only be interested in the last value of the property, not the next
value.

As I understand things, isset() performs 2 tests. First a check to see
if the variable exists and then to see if it has a value assigned.

For a property, the first part of that equation is fairly simple - the
property has to exist or not.

The second part though is not easy. A variable will not change value
in response to isset(), but, if isset() calls the getter(), then it
could and probably would. Calling isset() shouldn't alter anything.

Agreed, isset should not alter anything.

Having isset() call the getter() and unset() call the setter() is fine
as long as the getter() and setter() know why they are being called.

If the developer needs to supply the last value - their choice - then
this could be implemented by caching the last value in a local scope
static. Completely encapsulated.

get($isset = false){
 static $lastValue;

 if (!$isset) {
  // Generate the new value and assign it to $lastValue
 }

 return $lastValue;
}

The major issue I see here, is that a property should not be generating a
value in an unpredictable way.  In the example above, you indicate that
the value could change just by calling the get method.  While it is
possible to write a property that does such a thing, this is completely
incorrect and should not be actively supported by the language in any way.
 The value of a property (as viewed from the outside of the class) should
never, ever change solely by a call to a getter method.

Basically what this means, is that two subsequent calls to a get method of
a property should ALWAYS return the same value.  I think this is the only
scenario that we should care to support, and if the user is changing
values in a getter method, then they need to understand that isset may not
work as desired.

If you need to generate and return a random or similar value, that should
be done as a method.  See the MSDN article "Choosing Between Properties
and Methods" for more details:

http://msdn.microsoft.com/en-us/library/ms229054.aspx

Isset should be a direct reflection of the value that is/will be returned
by the getter method.  If you call isset() on a property, you are asking
"if this property exists, and I access it, will I get a non-null value?".

Not only that, an $isset parameter is ugly and cumbersome, and complicates
a feature that is meant to simplify a programmers life.

Having isset and unset methods alongside the get/set methods seems
reasonable to me, for the situations that you do need to handle those
operations explicitly, but I do not think an isset/unset implementation
should be required in every case (meaning there must be a default way of
handling that functionality), or else properties will be avoided by
programmers due to being to complicated to create.

• Dennis

In a multiuser environment (where I do all my work), the current
instance of an object may (and will probably will) contain stale data.

Take something simple, say, a sales order processing system (SOP).

Amongst all the data held in the system, there are 3 important
properties to consider which cannot be altered by the sales order
processing system.

1 - Credit Limit - can only be altered by the Sales Ledger (SL) system

• in an SOP scenario, the credit limit is read-only.
  2 - Account Balance - depending upon the process in the SOP, this
  instance may or may not be able to alter this value. Order entry -
  readonly. Raising invoices for despatched orders (assuming no middle
  land "posting" mechanism between SOP and SL), then writable.
  3 - On Order Total (the value of all outstanding orders) - Like the
  Account Balance, this instance will not be the only entity capable
  of altering this value - many users in SOP will be creating new orders
  in real time. Invoice production for despatched orders will also alter
  this value.

A fourth important value in this equation is ...

4 - Current Order Value - for the sake of argument, only this
instance can alter this value. Implemented as a getter() to a private
variable fed by order details and order calculations - order discount,
Tax/VAT, etc.

The first 3 are retrieved from a cached, low TTL database request.

The fourth could simply be a cached value with a write-through to the
DB. This would allow the work in progress to be seen live, even though
the order isn't yet finalised. This is extremely useful in realtime
for features like realtime stock allocation.

An important attribute of an account is the available balance. This is
the normally the value that would be available if all outstanding
orders were fulfilled, combined with their current balance and
compared against their credit limit.

In a multi-user system, any of these values could be different from
one moment to the next.

class Account{
public property $AvailableBalance{
get{
return $this->CreditLimit - ($this->AccountBalance - $this->OnOrder);
}
}
}

This hides the mechanics away and tells any user that the account for
this order has a realtime $CreditLimit, $AccountBalance, $OnOrder and
an accurate $AvailableBalance. At the beginning and end of the order
entry and maybe as each line is being entered, the AvailableBalance is
accessed to see if it the current order can be met financially.

The Account's properties are all read-only in this scenario (I'd have
2 Account classes, one for the Sales Ledger and a subclass for
everywhere else. The ability to essentially remove the setter() in a
subclass would turn a read/write property into a readonly property).

So, based upon this fairly simple scenario, isset() would clearly
alter the value of the account's properties if it had to call the
getter()s.

And, in this example, no great harm would be caused by doing so. But
it would certainly be an unnecessary overhead to do so.

You say "While it is possible to write a property that does such a
thing, this is completely incorrect and should not be actively
supported by the language in any way.".

How are you going to stop me from writing code that DOES generate a
new and appropriate value in response to a getter() request.

Surely that's the exact job of a getter()? To generate and supply a
potentially new and accurate value. Not to supply some pre-hashed
value which is accessible via __get() or by directly accessing a
public variable (as seen in the EmployeeRecord on the MSDN link you
gave - completely pointless).

You may come back and say the mechanics should be ...

public function getAvailableBalance() {
return $this->getCreditLimit() - ($this->getAccountBalance() -
$this->getOnOrder()) - $this->getOrderValue();
}

with each property being retrieved by an appropriate method (as
suggested in the MSDN article - computationally expensive for a
property).

But the nett effect is the same. The DB (probably via a cache with a
low TTL) would still be hit - in fact it would need to hit as we need
live data for the calculations.

The end-user would have to type a few more letters and think in terms
of "behaviour" rather than "attribute" in terms of accessing the
value.

This is the current way you'd have to write the code.

If that is what you say I should do, then I ask what are the
benefits of using properties for me?

At best, it seems like a way to allow separate docblocks and
readonly/writeonly. If the getter can't return a different value then
it really doesn't seem that useful.

I'd expect a property to provide the value of an attribute of the
object. Properties would also allow the developer to respond to
requests to supply or alter the attribute and limit/allow that
request. The value of a property/attribute can be different. A Clock
object can have a time attribute. You can't change time (Einstein and
Hawking may argue differently). So I have think in terms of retrieving
the time from my clock rather than thinking in terms of a clock has a
time property.

The response to isset/unset can only sensibly be handed by the
designer of the property. Either as additional isset()/unset()
functions in the property, or as a flag to the get()/set() functions
(my favourite).

Richard.

Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY