Patch: getters/setters syntax Implementation

13 years ago by Rasmus Schultz — view source

unread

2011/12/4 Clint M Priest cpriest@zerocue.com:

Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch

In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the object and the system looks for those
functions and calls them at the appropriate time.

Example:
class z {
public $Hours {
public get { return $this->_Hours; }
protected set { $this->_Hours = $value; }
}
}

Defines:
$o->__getHours();
$o->__setHours($value);

You forgot to declare the backing field z::$_Hours in this example.

From a semantic point of view, I find it misleading to first declare $Hours
as public, then lowering the bar by making the set-accessor protected.

The most common use-case for accessors is public - so I would suggest a
syntax more along the lines of this:

class z {
private $_hours;

get $hours { // accessor is public by default
return $this->_hours;
}

protected set $hours {
$this->_hours = $hours; // local variable $hours is the new value
}
}

And perhaps a short form for added convenience, where the backing-field is
automatically added for you - e.g.:

class z {
get $hours { // accessor is public by default
return $value; // $value provides access to the backing field (same way
$this provides access to the object context)
}

protected set $hours {
$value = $hours; // local variable $hours is the new value, $value
references the backing field
}
}

thoughts?

13 years ago by Clint M Priest — view source

unread

I believe the attempt with the RFC was to mimic the syntax that C# went with, the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax

The first public would apply to either of the get/set which did not have it further defined, for example:

public $Hours {
get { ... }
private set { ... }
}

Also, with automatic implementations (at present) the parent access level controls the automatic property generation:

private $Hours {
public get;
public set;
}

Would define an internal variable of $__Hours as private. Perhaps it should always be a private internal variable, it was not designated in the rfc and I made it this way to be the most flexible for the author.

-----Original Message-----
From: Rasmus Schultz [mailto:rasmus@mindplay.dk]
Sent: Monday, December 05, 2011 5:11 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: Patch: getters/setters syntax Implementation

2011/12/4 Clint M Priest cpriest@zerocue.com:

Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch

In the end it is a relatively simple patch. The new syntax
effectively
creates internal functions on the object and the system looks for those functions and calls them at the appropriate time.

Example:
class z {
public $Hours {
public get { return $this->_Hours; }
protected set { $this->_Hours = $value; }
}
}

Defines:
$o->__getHours();
$o->__setHours($value);

You forgot to declare the backing field z::$_Hours in this example.

From a semantic point of view, I find it misleading to first declare $Hours as public, then lowering the bar by making the set-accessor protected.

The most common use-case for accessors is public - so I would suggest a syntax more along the lines of this:

class z {
private $_hours;

get $hours { // accessor is public by default
return $this->_hours;
}

protected set $hours {
$this->_hours = $hours; // local variable $hours is the new value
}
}

And perhaps a short form for added convenience, where the backing-field is automatically added for you - e.g.:

class z {
get $hours { // accessor is public by default
return $value; // $value provides access to the backing field (same way $this provides access to the object context)
}

protected set $hours {
$value = $hours; // local variable $hours is the new value, $value references the backing field
}
}

thoughts?

13 years ago by Christian Kaps — view source

unread

Hi,

I also find this syntax confusing and I think it has a huge WTF factor.

Some thoughts about the syntax:

At the first glance, it isn't clear which visibility the getter or
setter has
The extra indentation level makes the code more unreadable

class Foo {

 /**
  *
  */
 private $_bar;

 /**
  *
  */
 public $bar{

     /**
      *
      */
     set {
         if ($bar) {
             $this->_bar = $bar * 12;
         } else {
             $this->_bar = 0
         }
     }

     /**
      *
      */
     private set {
         if ($this->_bar === null) {
             return 0;
         }

         return $this->_bar;
     }
 }

 /**
  *
  */
 public function baz() {

 }

}

What about type hints?

I prefer a more AS3 like getter and setter syntax.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb

Have you read my previous mail http://news.php.net/php.internals/56762.
I think this syntax fits more to PHP because its similar to the already
existing(magic) getter and setter syntax.

What do you think?

Christian

Am 06.12.2011 04:23, schrieb Clint M Priest:

I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax

The first public would apply to either of the get/set which did not
have it further defined, for example:

public $Hours {
get { ... }
private set { ... }
}

Also, with automatic implementations (at present) the parent access
level controls the automatic property generation:

private $Hours {
public get;
public set;
}

Would define an internal variable of $__Hours as private. Perhaps it
should always be a private internal variable, it was not designated
in
the rfc and I made it this way to be the most flexible for the
author.

-----Original Message-----
From: Rasmus Schultz [mailto:rasmus@mindplay.dk]
Sent: Monday, December 05, 2011 5:11 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: Patch: getters/setters syntax Implementation

2011/12/4 Clint M Priest cpriest@zerocue.com:

Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch

In the end it is a relatively simple patch. The new syntax
effectively
creates internal functions on the object and the system looks for
those functions and calls them at the appropriate time.

Example:
class z {
public $Hours {
public get { return $this->_Hours; }
protected set { $this->_Hours = $value; }
}
}

Defines:
$o->__getHours();
$o->__setHours($value);

You forgot to declare the backing field z::$_Hours in this example.

From a semantic point of view, I find it misleading to first declare
$Hours as public, then lowering the bar by making the set-accessor
protected.

The most common use-case for accessors is public - so I would suggest
a syntax more along the lines of this:

class z {
private $_hours;

get $hours { // accessor is public by default
return $this->_hours;
}

protected set $hours {
$this->_hours = $hours; // local variable $hours is the new value
}
}

And perhaps a short form for added convenience, where the
backing-field is automatically added for you - e.g.:

class z {
get $hours { // accessor is public by default
return $value; // $value provides access to the backing field
(same way $this provides access to the object context)
}

protected set $hours {
$value = $hours; // local variable $hours is the new value,
$value references the backing field
}
}

thoughts?

13 years ago by Rasmus Schultz — view source

unread

On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps christian.kaps@mohiva.comwrote:

Hi,

I also find this syntax confusing and I think it has a huge WTF factor.

Some thoughts about the syntax:

At the first glance, it isn't clear which visibility the getter or
setter has

The extra indentation level makes the code more unreadable

class Foo {

/**
*
*/
private $_bar;

/**
*
*/
public $bar{
   /**
    *
    */
   set {
       if ($bar) {
           $this->_bar = $bar * 12;
       } else {
           $this->_bar = 0
       }
   }

   /**
    *
    */
   private set {
       if ($this->_bar === null) {
           return 0;
       }

       return $this->_bar;
   }
}

/**
*
*/
public function baz() {

}
}

What about type hints?

I prefer a more AS3 like getter and setter syntax.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/
WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#**
WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcbhttp://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb

Have you read my previous mail http://news.php.net/php.**internals/56762 http://news.php.net/php.internals/56762
.
I think this syntax fits more to PHP because its similar to the already
existing(magic) getter and setter syntax.

What do you think?

Christian

I agree with all of those points - the extra indentation looks messy, and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
    return $this->_author;
}

public set author(Person $value)
{
    $this->_author = $value;
}

}

Could be written like this:

class BlogPost
{
public Person $author;
}

Effectively, this shorthand syntax just gives you type-safe properties -
but it refactors nicely, since you can replace it with a full
implementation of a backing field at any point.

(on second thought, I don't like the idea I suggested before - adding a
magical $value in accessors, similar to $this - it's confusing and it's
going to look like an undeclared local variable...)

13 years ago by Sebastian Krebs — view source

unread

2011/12/6 Rasmus Schultz rasmus@mindplay.dk

On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps <christian.kaps@mohiva.com

wrote:
Hi,

I also find this syntax confusing and I think it has a huge WTF factor.

Some thoughts about the syntax:

At the first glance, it isn't clear which visibility the getter or
setter has

The extra indentation level makes the code more unreadable

class Foo {

/**
*
*/
private $_bar;

/**
*
*/
public $bar{
   /**
    *
    */
   set {
       if ($bar) {
           $this->_bar = $bar * 12;
       } else {
           $this->_bar = 0
       }
   }

   /**
    *
    */
   private set {
       if ($this->_bar === null) {
           return 0;
       }

       return $this->_bar;
   }
}

/**
*
*/
public function baz() {

}
}

What about type hints?

I prefer a more AS3 like getter and setter syntax.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/
WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#**
WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcb<
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb

Have you read my previous mail http://news.php.net/php.**internals/56762
http://news.php.net/php.internals/56762
.
I think this syntax fits more to PHP because its similar to the already
existing(magic) getter and setter syntax.

What do you think?

Christian
I agree with all of those points - the extra indentation looks messy, and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
return $this->_author;
}

public set author(Person $value)
{
$this->_author = $value;
}
}

Could be written like this:

class BlogPost
{
public Person $author;
}

Effectively, this shorthand syntax just gives you type-safe properties -
but it refactors nicely, since you can replace it with a full
implementation of a backing field at any point.

(on second thought, I don't like the idea I suggested before - adding a
magical $value in accessors, similar to $this - it's confusing and it's
going to look like an undeclared local variable...)

Because it seems everybody throws in their preferred syntax :X

class X {
public $myProperty {
/* public inherited / set (AnotherClass $value) { // Value from
"outside"
return $value; // Set to property
}
private get (AnotherClass $value) { // Value from property (Maybe with
typehint)
return $value; // returns value to the caller
}
} / = 'default value'; */;
}

No magic $value
Type-Hints
I think nearly no suprise, what happens here

In my eyes the goal should be to not separate a property from its
accessor anymore, which disqualifies both of Rasmus Schultz suggestions. At
least this is the reason, why I want to see this RFC to be implemented.

13 years ago by Will Fitch — view source

unread

On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps christian.kaps@mohiva.comwrote:
Hi,

I also find this syntax confusing and I think it has a huge WTF factor.

Some thoughts about the syntax:

At the first glance, it isn't clear which visibility the getter or
setter has

The extra indentation level makes the code more unreadable

class Foo {

/**

*/
private $_bar;

/**

*/
public $bar{
  /**
   *
   */
  set {
      if ($bar) {
          $this->_bar = $bar * 12;
      } else {
          $this->_bar = 0
      }
  }

  /**
   *
   */
  private set {
      if ($this->_bar === null) {
          return 0;
      }

      return $this->_bar;
  }
}

/**

*/
public function baz() {

}
}

What about type hints?

I prefer a more AS3 like getter and setter syntax.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/
WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#**
WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcbhttp://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb

Have you read my previous mail http://news.php.net/php.**internals/56762 http://news.php.net/php.internals/56762
.
I think this syntax fits more to PHP because its similar to the already
existing(magic) getter and setter syntax.

What do you think?

Christian
I agree with all of those points - the extra indentation looks messy, and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
return $this->_author;
}

public set author(Person $value)
{
$this->_author = $value;
}
}

I don't like this approach. All efforts (which I'm currently part of) to implement type hinting return values will be compromised. If you want to implement accessors, keep them within a syntax that makes sense. Personally, I support the C# style as much as possible. Methods are already overused for purposes they shouldn't be, so if we're attempting to get around __set/get, let's not replace them with more method implementations.

Could be written like this:

class BlogPost
{
public Person $author;
}

Effectively, this shorthand syntax just gives you type-safe properties -
but it refactors nicely, since you can replace it with a full
implementation of a backing field at any point.

(on second thought, I don't like the idea I suggested before - adding a
magical $value in accessors, similar to $this - it's confusing and it's
going to look like an undeclared local variable...)

13 years ago by Rasmus Schultz — view source

unread

if we're attempting to get around __set/get, let's not replace them with
more method implementations

I don't understand this argument. Accessors are methods - making them look
like something else won't change that fact.

In C#, type-hinted properties with automatic getters/setters actually
compile down to two method implementations, while implemented
getters/settings do the same, substituting "value" for whatever is required
to access the auto-implemented backing field.

I agree with all of those points - the extra indentation looks messy, and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
return $this->_author;
}

public set author(Person $value)
{
$this->_author = $value;
}
}

I don't like this approach. All efforts (which I'm currently part of) to
implement type hinting return values will be compromised. If you want to
implement accessors, keep them within a syntax that makes sense.
Personally, I support the C# style as much as possible. Methods are
already overused for purposes they shouldn't be, so if we're attempting to
get around __set/get, let's not replace them with more method
implementations.

13 years ago by Will Fitch — view source

unread

The difference being where the functionality gets mapped. It's not about making something "look like something else", it's about requiring more userspace definitions. Functionality within get {} and set {} can (and should IMO) be implemented outside of userspace code. Whether that means another union within op_array or a completely new structure mapped to a property zval and bitmap added to the zend_uchar type identifying it as an accessor.... I'm saying be creative - don't just implement something halfway for the sake of getting it done.

if we're attempting to get around __set/get, let's not replace them with
more method implementations

I don't understand this argument. Accessors are methods - making them look
like something else won't change that fact.

In C#, type-hinted properties with automatic getters/setters actually
compile down to two method implementations, while implemented
getters/settings do the same, substituting "value" for whatever is required
to access the auto-implemented backing field.

I agree with all of those points - the extra indentation looks messy, and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
return $this->_author;
}

public set author(Person $value)
{
$this->_author = $value;
}
}

I don't like this approach. All efforts (which I'm currently part of) to
implement type hinting return values will be compromised. If you want to
implement accessors, keep them within a syntax that makes sense.
Personally, I support the C# style as much as possible. Methods are
already overused for purposes they shouldn't be, so if we're attempting to
get around __set/get, let's not replace them with more method
implementations.

13 years ago by Rasmus Schultz — view source

unread

I have no opinion about how it gets implemented under the hood - I thought
we were just discussing the syntax. I most likely don't know enough about
the innards of PHP it carry on that discussion.

But by userspace definitions, are you referring to the fact that getters
and setters would compile down to actual methods? I have no strong feelings
about that one way or the other - as long as the reflection API reports
what was defined in the source code, rather than reflecting the underlying
accessor-methods as actual methods. (something that doesn't seem to be true
for traits...)

I don't know if that's meaningful or relevant to you, but I think that's
all I can contribute to that discussion...

The difference being where the functionality gets mapped. It's not
about making something "look like something else", it's about requiring
more userspace definitions. Functionality within get {} and set {} can
(and should IMO) be implemented outside of userspace code. Whether that
means another union within op_array or a completely new structure mapped to
a property zval and bitmap added to the zend_uchar type identifying it as
an accessor.... I'm saying be creative - don't just implement something
halfway for the sake of getting it done.

if we're attempting to get around __set/get, let's not replace them with
more method implementations

I don't understand this argument. Accessors are methods - making them
look
like something else won't change that fact.

In C#, type-hinted properties with automatic getters/setters actually
compile down to two method implementations, while implemented
getters/settings do the same, substituting "value" for whatever is
required
to access the auto-implemented backing field.

I agree with all of those points - the extra indentation looks messy,
and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
return $this->_author;
}

public set author(Person $value)
{
$this->_author = $value;
}
}

I don't like this approach. All efforts (which I'm currently part of)
to
implement type hinting return values will be compromised. If you want
to
implement accessors, keep them within a syntax that makes sense.
Personally, I support the C# style as much as possible. Methods are
already overused for purposes they shouldn't be, so if we're attempting
to
get around __set/get, let's not replace them with more method
implementations.

13 years ago by Will Fitch — view source

unread

I'm saying that when you define an accessor, the body of the get/set functionality is contained within get {} and set {}, just like C#. I'm referencing your suggestion to automatic backing fields. There's no need for the backup.

Reflection for accessors should be treated the same as the rest. Since there is a definition for each get and set, Reflection{Property/Accessor} should treat invocations of those separately, so I agree with that, but Reflection hasn't failed us so far. :)

I have no opinion about how it gets implemented under the hood - I thought
we were just discussing the syntax. I most likely don't know enough about
the innards of PHP it carry on that discussion.

But by userspace definitions, are you referring to the fact that getters
and setters would compile down to actual methods? I have no strong feelings
about that one way or the other - as long as the reflection API reports
what was defined in the source code, rather than reflecting the underlying
accessor-methods as actual methods. (something that doesn't seem to be true
for traits...)

I don't know if that's meaningful or relevant to you, but I think that's
all I can contribute to that discussion...

The difference being where the functionality gets mapped. It's not
about making something "look like something else", it's about requiring
more userspace definitions. Functionality within get {} and set {} can
(and should IMO) be implemented outside of userspace code. Whether that
means another union within op_array or a completely new structure mapped to
a property zval and bitmap added to the zend_uchar type identifying it as
an accessor.... I'm saying be creative - don't just implement something
halfway for the sake of getting it done.

if we're attempting to get around __set/get, let's not replace them with
more method implementations

I don't understand this argument. Accessors are methods - making them
look
like something else won't change that fact.

In C#, type-hinted properties with automatic getters/setters actually
compile down to two method implementations, while implemented
getters/settings do the same, substituting "value" for whatever is
required
to access the auto-implemented backing field.

I agree with all of those points - the extra indentation looks messy,
and
yes, type hints are important. It does fit better with PHP in general.

It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:

class BlogPost
{
private $_author;

public get author()
{
return $this->_author;
}

public set author(Person $value)
{
$this->_author = $value;
}
}

I don't like this approach. All efforts (which I'm currently part of)
to
implement type hinting return values will be compromised. If you want
to
implement accessors, keep them within a syntax that makes sense.
Personally, I support the C# style as much as possible. Methods are
already overused for purposes they shouldn't be, so if we're attempting
to
get around __set/get, let's not replace them with more method
implementations.

13 years ago by Pierre Joye — view source

unread

I believe the attempt with the RFC was to mimic the syntax that C# went with, the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax

C# like setter/getter is definitely what I would like to have in PHP,
it is a very clear and known syntax, while being features rich.

Cheers,

Pierre

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

13 years ago by Clint M Priest — view source

unread

I prefer C# syntax myself but thinking about it, supporting both syntax's would be fairly trivial to add... Thoughts on that?

-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, December 06, 2011 5:47 AM
To: Clint M Priest
Cc: Rasmus Schultz; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Patch: getters/setters syntax Implementation

I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax

C# like setter/getter is definitely what I would like to have in PHP, it is a very clear and known syntax, while being features rich.

Cheers,

Pierre

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

13 years ago by Stas Malyshev — view source

unread

Hi!

I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax

Reading this RFC I notice it makes get/set keywords. This would lead to
huge amount of breakage in existing code, so I strongly suggest to look
for another way. For example, __get and __set...

I'm also not a big fan of magic $value variable coming from nowhere and
function syntax without function definition. What if you want a getter
to return by-reference? Or setter to get parameter by reference?

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

13 years ago by Nikita Popov — view source

unread

The implementation specifically didn't introduce T_GET/T_SET on the
lexer side and instead checks for T_STRINGs with content "get" or
"set".

Nikita

Hi!

I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax

Reading this RFC I notice it makes get/set keywords. This would lead to
huge amount of breakage in existing code, so I strongly suggest to look
for another way. For example, __get and __set...

I'm also not a big fan of magic $value variable coming from nowhere and
function syntax without function definition. What if you want a getter to
return by-reference? Or setter to get parameter by reference?

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