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

- Thread: https://externals.io/message/50675
- Original archive: https://news-web.php.net/php.internals/50675
- Started by president@basnetworks.net on 2010-11-28T23:18:40+00:00
- Messages: 70
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/50675.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #50675 — president@basnetworks.net — 2010-11-28T23:18:40+00:00

URL: https://externals.io/message/50675#50675

Hello,

This is my first time using a mailing list, so please bear with me.

Some time back I suggested that PHP should have a property get/set syntax
similar to that of Microsoft's C# language.  One of the PHP developers
suggested that if I were serious about it, I should write an RFC.  I have
done just that, and I would now like to present my RFC to everyone here in
internals, in order to start a discussion on the topic.

The RFC:

Many modern languages have a special syntax for writing get/set method
pairs.  All that PHP currently supports is __get and __set, which while
great for writing generic get/set methods is nearly useless when it comes
to individual properties.  Our only other choice is the age old process of
writing custom class methods to make our get/set methods.  Not only does
this lack any kind of uniformity, but it also complicates the syntax
($foo->getBar() and $foo->setBar('baz') instead of $foo->bar and
$foo->bar='baz').  I believe that if PHP is going embrace modern
object-oriented design, including encapsulation, than it needs a modern
solution to property getters and setters.

I wont add much more here, but rather let the RFC itself do the talking. 
It is fairly well fleshed out, and should explain everything clearly
enough.

Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax

Thanks,
Dennis Robinson

---

## #50676 — Larry Garfield — 2010-11-29T00:15:12+00:00

URL: https://externals.io/message/50675#50676 · In reply to: #50675

> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
> 
> Thanks,
> Dennis Robinson

This is a very well-written and well-thought through RFC, Dennis.  Nicely 
done.

That said, I am not yet convinced. :-)

First of all, I have generally found the Bean-style getter/setter approach to 
be a sign of poor encapsulation to begin with.  You shouldn't be mucking with 
internal elements of an object in the first place, period.  More details on 
that here:

http://www.garfieldtech.com/blog/property-visibility

However, I do see a potential use here if "properties" are treated 
conceptually as an entirely new concept and not as an indirection layer for 
class properties.  That would make them more akin to a class that has both 
methods and also implements ArrayAccess for "properties of the conceptual 
object, that may not have anything to do with internal class members."

Viewed from that angle, I would have the following comments:

- I strongly prefer the first syntax over the second.  The "property" keyword 
improves readability, and the closing semi-colon is going to be forgotten on a 
daily basis.  I still forget sometimes when to use it and when not to when 
writing Javascript. :-)  I cannot speak to the engine complexity involved but 
from a PHP-autor point of view I believe the first syntax is much easier to 
use.

- The use of identical syntax for class members and properties could create 
confusion as to which is which.  One could argue that is the point, but only 
if we view properties as "just" an indirection layer around the physical class 
members, which as I noted above I believe is a poor architectural design.  
There may not be an alternative here, but I mention it for completeness.

- I concur with the RFP's preference for "implicit write-only" properties 
rather than explicit, as it seems more flexible.

- The layering of accessibility keywords I find intriguing, in a mostly good 
way.  That can offer a great deal of flexibility to control who can do what 
when.  However, I am concerned about the confusion possible in the following:

public property Hours {
  get { return $this->seconds / 3600; }
  protected set { $this->seconds = $value * 3600; }
}

The set method is then scoped with two different visibility directives: public 
and protected.  Which applies?  Since both are optional (presumably) I can see 
a potential here for confusion, especially if you also start mentioning 
keywords like final.  This should be made more definitive if possible.

- If interfaces can declare properties (niiice), Traits should be able to 
provide them.  That provides full parallelism with methods, which I believe 
developers will expect.

- I am curious what the performance implication would be.  For instance, I've 
benchmarked both magic property access (__get()) and ArrayAccess to be around 
4 times as slow as accessing a class member. 

http://www.garfieldtech.com/blog/benchmarking-magic

Since in essence what is happening here is binding a function to fire when a 
class member is accessed (given the identical syntax), I'm concerned that 
there would be a similar performance issue.  A 4x slower performance cost 
would make me avoid properties in favor of class members unless I absolutely 
needed them.  A 2x or less I could see making more use of.

- Which also brings up an interesting question:

class Foo {
  public $a = 1;
  protected $b = 2;

  public property $a { get { return 3; } }
  public property $b { get { return 4; } }
}

$f = new Foo();
print $f->a . PHP_EOL; // Does this print 1 or 3?
print $f->b . PHP_EOL; // Does this print 2 or 4, or error?

I'm sure there's arguments every which way.  My preference would be for 
properties to always win over class members, followed by the above code sample 
being a compile error.

It gets even tricker when you introduce inheritance.  If a child class has a 
[property|class member] of the same name as a parent's [class member|
property], then what?

That's all I got for now.  Once again, nice RFP but still needs some thinking.

--Larry Garfield

---

## #50677 — Pierre Joye — 2010-11-29T00:22:43+00:00

URL: https://externals.io/message/50675#50677 · In reply to: #50675

hi,

Great job, very well written proposal.

Quick notice: the readonly keyword work without being used with a
method (or the default getter/setter):

class A {
  public readonly propro;
}

The writeonly property (useful from time to time) is not supported by
default but using the custom definitions.

I'm all in favour of having that in PHP. However not in an immediate
future (ie 5.4) but the next major version.

Cheers,


> Hello,
>
> This is my first time using a mailing list, so please bear with me.
>
> Some time back I suggested that PHP should have a property get/set syntax
> similar to that of Microsoft's C# language.  One of the PHP developers
> suggested that if I were serious about it, I should write an RFC.  I have
> done just that, and I would now like to present my RFC to everyone here in
> internals, in order to start a discussion on the topic.
>
> The RFC:
>
> Many modern languages have a special syntax for writing get/set method
> pairs.  All that PHP currently supports is __get and __set, which while
> great for writing generic get/set methods is nearly useless when it comes
> to individual properties.  Our only other choice is the age old process of
> writing custom class methods to make our get/set methods.  Not only does
> this lack any kind of uniformity, but it also complicates the syntax
> ($foo->getBar() and $foo->setBar('baz') instead of $foo->bar and
> $foo->bar='baz').  I believe that if PHP is going embrace modern
> object-oriented design, including encapsulation, than it needs a modern
> solution to property getters and setters.
>
> I wont add much more here, but rather let the RFC itself do the talking.
> It is fairly well fleshed out, and should explain everything clearly
> enough.
>
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
>
> Thanks,
> Dennis Robinson
>
>
> --
> 
> 
>
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #50681 — Christian Kaps — 2010-11-29T07:48:44+00:00

URL: https://externals.io/message/50675#50681 · In reply to: #50675

Hi,

 I like the idea of the property get/set syntax, but in my opinion it 
 doesn't figure with PHP's syntax, because it breaks the readability. The 
 problem for me is the nesting of the inner set and get. How do you 
 document these syntax.

 /**
  *
  */
 public $name {

     /**
      *
      */
     get {
         return $this->name;
     }

     /**
      *
      */
     set {
         $this->name = htmlentities($value);
         $this->name = strip_tags($this->name);
     }
 };


 What I also miss is the lack of type hinting. As I see it, it isn't 
 possible with this syntax.

 I would prefer the syntax from ActionScript. This is more like the 
 normal PHP function syntax with an additional set or get keyword.

 /**
  *
  */
 public function set name(string $name) {
     $this->name = htmlentities($name);
     $this->name = strip_tags($this->name);
 }

 /**
  *
  */
 public function get name($name) {
     return $this->name;
 }

 Greetings,
 Christian

 
> Hello,
>
> This is my first time using a mailing list, so please bear with me.
>
> Some time back I suggested that PHP should have a property get/set 
> syntax
> similar to that of Microsoft's C# language.  One of the PHP 
> developers
> suggested that if I were serious about it, I should write an RFC.  I 
> have
> done just that, and I would now like to present my RFC to everyone 
> here in
> internals, in order to start a discussion on the topic.
>
> The RFC:
>
> Many modern languages have a special syntax for writing get/set 
> method
> pairs.  All that PHP currently supports is __get and __set, which 
> while
> great for writing generic get/set methods is nearly useless when it 
> comes
> to individual properties.  Our only other choice is the age old 
> process of
> writing custom class methods to make our get/set methods.  Not only 
> does
> this lack any kind of uniformity, but it also complicates the syntax
> ($foo->getBar() and $foo->setBar('baz') instead of $foo->bar and
> $foo->bar='baz').  I believe that if PHP is going embrace modern
> object-oriented design, including encapsulation, than it needs a 
> modern
> solution to property getters and setters.
>
> I wont add much more here, but rather let the RFC itself do the 
> talking.
> It is fairly well fleshed out, and should explain everything clearly
> enough.
>
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
>
> Thanks,
> Dennis Robinson

---

## #50684 — Chad Fulton — 2010-11-29T08:36:52+00:00

URL: https://externals.io/message/50675#50684 · In reply to: #50681

On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
<christian.kaps@mohiva.com> wrote:
...

> /**
>  *
>  */
> public function set name(string $name) {
>    $this->name = htmlentities($name);
>    $this->name = strip_tags($this->name);
> }
>
> /**
>  *
>  */
> public function get name($name) {
>    return $this->name;
> }
>
> Greetings,
> Christian
>

For whatever it's worth, I think that this syntax fits much better
into PHP than do either of the those in the RFC.

---

## #50686 — Richard Quadling — 2010-11-29T10:53:40+00:00

URL: https://externals.io/message/50675#50686 · In reply to: #50675

> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
>
> Thanks,
> Dennis Robinson

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.

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.

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.

The downside is certainly that the code is more verbose than I would
guess many people would like.

Regards,

Richard.

[1] http://www.delphibasics.co.uk/RTL.asp?Name=Property
-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

---

## #50690 — Jonathan Bond-Caron — 2010-11-29T14:23:14+00:00

URL: https://externals.io/message/50675#50690 · In reply to: #50675

> 
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
> 

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

Would favor re-use similar to traits by injecting the set/get code around
the property.

---

## #50691 — Stas Malyshev — 2010-11-29T14:27:33+00:00

URL: https://externals.io/message/50675#50691 · In reply to: #50690

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 :)

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #50692 — keisial@gmail.com — 2010-11-29T14:30:27+00:00

URL: https://externals.io/message/50675#50692 · In reply to: #50686

Richard Quadling wrote:
> 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.
>
> 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.
>
> 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.
>
> The downside is certainly that the code is more verbose than I would
> guess many people would like.
>
> Regards,
>
> Richard.
>
> [1] http://www.delphibasics.co.uk/RTL.asp?Name=Property

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.

---

## #50693 — Matthew Weier O'Phinney — 2010-11-29T14:55:52+00:00

URL: https://externals.io/message/50675#50693 · In reply to: #50686

> 
> > […]
>
> 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.
>
> 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;
>     }

<snip>

> 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.

I prefer this as well. It often aids readability to use fluent
interfaces when performing operations that are simply changing state,
and being able to call the setters directly would make that possible:

$time->setHours(3)
     ->setMinutes(17)
     ->setSeconds(34);

Additionally, this seems like a very natural fit with traits, making it
possible to really succinctly define behavior to mix in with classes.

-- 
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

---

## #50694 — Matthew Weier O'Phinney — 2010-11-29T14:55:56+00:00

URL: https://externals.io/message/50675#50694 · In reply to: #50691

> > […]
>
> 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

---

## #50696 — Stas Malyshev — 2010-11-29T15:08:23+00:00

URL: https://externals.io/message/50675#50696 · In reply to: #50686

Hi!

>      public property Hours read getHours write setHours;

I actually like that, though I think we should support the whole 
existing semantics, i.e. get/set/isset/unset. And probably keep the 
names, so we don't call the same thing both "read" and "get".

Having them called __get etc. would even remove the need for another 
keyword, probably, but this looks ugly :(
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #50697 — Richard Quadling — 2010-11-29T16:10:13+00:00

URL: https://externals.io/message/50675#50697 · In reply to: #50692

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

---

## #50701 — Jonathan Bond-Caron — 2010-11-29T17:51:53+00:00

URL: https://externals.io/message/50675#50701 · In reply to: #50691

> Hi!
> 
> > […]
> #2):
> > […]
> holds
> > […]
> 
> 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;
}

---

## #50702 — larry@garfieldtech.com — 2010-11-29T18:14:42+00:00

URL: https://externals.io/message/50675#50702 · In reply to: #50701

> 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):

I think I'd prefer to use Traits for externally-defined properties 
rather than defining a new top-level construct.  It's fewer moving parts 
and we don't need to figure out how autoloading would be affected. 
(Autoload would work the same way it does now for traits... whatever 
that is.)

That would then imply we do need to be able to declare the existence of 
a property and whether it has get, set, or both independently of the 
definition, just like methods, so that we can have a proper 
interface/trait split for properties just as for methods.

--Larry Garfield

---

## #50703 — larry@garfieldtech.com — 2010-11-29T18:18:50+00:00

URL: https://externals.io/message/50675#50703 · In reply to: #50692

> 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

---

## #50704 — johannes@schlueters.de — 2010-11-29T18:41:56+00:00

URL: https://externals.io/message/50675#50704 · In reply to: #50703

> 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.

Don't kow what you mean by "the engine" in this case? The compiler? - no
the compiler can't a) it has no idea what type $foo is b) think about
inheritance etc. The executor - well there's no win possible.

johannes

---

## #50705 — larry@garfieldtech.com — 2010-11-29T19:40:05+00:00

URL: https://externals.io/message/50675#50705 · In reply to: #50704

> 
> > […]
>
> Don't kow what you mean by "the engine" in this case? The compiler? - no
> the compiler can't a) it has no idea what type $foo is b) think about
> inheritance etc. The executor - well there's no win possible.
>
> johannes

I was referring to the compiler I guess.  I don't do C so I have no idea 
what it's capable of.  If that's not a possible performance optimization 
point, then blargh.

I still want to keep the performance implications in mind, as this 
sounds like something that we'd want to use a lot but could also cost a 
lot more than it seems at first glance if we're not careful.

--Larry Garfield

---

## #50706 — johannes@schlueters.de — 2010-11-29T19:56:57+00:00

URL: https://externals.io/message/50675#50706 · In reply to: #50705

> I still want to keep the performance implications in mind, as this 
> sounds like something that we'd want to use a lot but could also cost a 
> lot more than it seems at first glance if we're not careful.

By making properties in memory a little bigger one might write the
accessors in the same table as the actual properties one might possibly
reduce the CPU requirement abit. While one has to touch most places
dealing with properties internally (while that's probably needed
anyways). But well, unless there is an implementation all performance
ideas are guesses ... educated guesses at best.

johannes

---

## #50707 — keisial@gmail.com — 2010-11-29T20:43:16+00:00

URL: https://externals.io/message/50675#50707 · In reply to: #50697

Richard Quadling wrote:
> 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.

If it begins with $, it's a variable name, so map to that class member
variable. If it is instead a plain T_STRING, take that as a member call.

I'm not sure to be understanding the issue you're mentioning.

---

## #50708 — Benjamin Dubois — 2010-11-29T20:47:39+00:00

URL: https://externals.io/message/50675#50708 · In reply to: #50697

Hi !

This is my first email here (I'm just a PHP user, with only very basic C skills, but I'm working on it), and I would love to contribute to this project.

I have been working with Objective-c lately, and it has a very flexible and short way to deal with properties, which could look like this in PHP : 

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


	@synthesize (readwrite) $hours,  $minutes;
	@synthesize (readonly) $seconds;
}

NB : I intentionally skipped the @property declaration wich I believe is a specific need for objc (used to allow dot syntax usage).


In objc, this notation allows to : 

- use dot syntax for accessing properties (using their getters/setters only, all properties are protected in objc)
- write your own getters/setters (only the missing ones are generated)


In Php, the pros of this syntax would be : 

- very concise
- no interference with existing code (except certain conditions)
- allows to override generated getters and setters with custom code
- may work with the existing code base

The cons : 

- new syntax to learn (even if it is quite simple)
- need to use pre-determined setters and getters names to keep simplicity, which could potentially lead to BC break in some (hopefully rare) cases.


What do you think about it ?


Regards, 

Benjamin
 



Le 29 nov. 2010 à 17:10, Richard Quadling a écrit :

> 2010/11/29 Ángel González <keisial@gmail.com>:
> > […]
> 
> 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

---

## #50724 — president@basnetworks.net — 2010-11-30T12:48:13+00:00

URL: https://externals.io/message/50675#50724 · In reply to: #50686

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

---

## #50727 — president@basnetworks.net — 2010-11-30T13:42:42+00:00

URL: https://externals.io/message/50675#50727 · In reply to: #50701

Hello,

> > […]
>
> 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;
> }


I do not think that properties should make use of a trait-like syntax, as
that is not what a property is about.  A property is basically a layer of
syntactic sugar over a pair of methods.  The majority of the time when
writing properties, you will not want to re-use them, so I have a hard
time seeing many parallels to traits.

However, it does make sense to be able to define a property as part of a
trait, as again, it is basically just a pair of methods.  When I get some
time, I will try to add a syntax for traits to the RFC.

- Dennis

---

## #50728 — Stefan Marr — 2010-11-30T13:49:45+00:00

URL: https://externals.io/message/50675#50728 · In reply to: #50727

Hi:



> However, it does make sense to be able to define a property as part of a
> trait, as again, it is basically just a pair of methods.  When I get some
> time, I will try to add a syntax for traits to the RFC.
The only thing really necessary for that would be a specification on how to name/to refer to the getter/setter to be able to handle the conflicts.
The rest should work out of the box. As far as I can see from the proposal.

Best regards
Stefna


> 
> - Dennis
> 
> 
> --
> 
> 
> 

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

---

## #50729 — Stas Malyshev — 2010-11-30T13:55:17+00:00

URL: https://externals.io/message/50675#50729 · In reply to: #50727

Hi!

> I do not think that properties should make use of a trait-like syntax, as
> that is not what a property is about.  A property is basically a layer of
> syntactic sugar over a pair of methods.  The majority of the time when
> writing properties, you will not want to re-use them, so I have a hard
> time seeing many parallels to traits.

A side note: in PHP, property actually has four methods, not two - 
get/set/unset/isset.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

Next page: https://externals.io/message/50675.md?page=2