Per RFC: https://wiki.php.net/rfc/propertygetsetsyntax
Alright, getters/setters has been built. This is my first patch to the php core. Here is what has been implemented:
http://www.clintpriest.com/patches/accessors_v1.patch (patch against trunk)
Asymmetrical getters/setters syntax:
public $Hours {
public get { return $this->_Hours; }
protected set { $this->_Hours = $value; } }
Default getter/setter implementations:
private $Hours { /* Implements private $__Hours; */
public get; /* { return $this->__Hours; }
public set; /* { $this->__Hours = $value; }
}
Interfaces (Forces implementation by implementing classes):
private $Hours {
get;
set;
}
Traits: No changes necessary, implementation worked without further changes
Errors: Updated errors to refer to getter/setter implementation when related
Note:
This does not interfere with typical __get()/__set() functionality which will take effect whenever there is not a specific getter/setter written.
I have also included 8 .phpt test files which tests the new functionality
What are the next steps to get this added to some future release?
Per RFC: https://wiki.php.net/rfc/propertygetsetsyntax
Alright, getters/setters has been built. This is my first patch to the php core. Here is what has been implemented:
http://www.clintpriest.com/patches/accessors_v1.patch (patch against trunk)
Could you create another patch that ignores the whitespace changes?
Its really annoying and confusing to read now.
What are the next steps to get this added to some future release?
See https://wiki.php.net/rfc/voting
-Hannes
hi Clint!
Thanks for your work so far!
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to
the voting phase. There is no need to hurry as the next release where
this patch could go in is next year.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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);
Standard __get()/__set() functionality checks for the more specifically defined function name and calls them. I thought this would make the most sense since it would allow us to leverage the existing inheritance functionality. This comes out with respect to interfaces and traits in that only errors had to be changed (for clarity) on interfaces and no changes to traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function body myself within zend_do_end_accessor_declaration(). One point of contention here is that internally it defines a __$Hours property which would be accessible from various points. I believe the standard C# get/set does not allow any access to the underlying data storage. In order to accomplish that there would need to be some non-standard storage or a super-private level or something. I did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
hi Clint!
Thanks for your work so far!
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the voting phase. There is no need to hurry as the next release where this patch could go in is next year.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
why not creating a more function like syntax for this feature. In my
opinion it looks more cleaner particularly when using more than one line
in a setter or getter. The other thing is that you can use type hints
with this syntax.
As example:
class Foo {
private $bar;
public set bar(Bar $bar) {
$this->bar = $bar;
}
public get bar() {
return $this->bar;
}
}
Christian
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);Standard __get()/__set() functionality checks for the more specifically defined function name and calls them. I thought this would make the most sense since it would allow us to leverage the existing inheritance functionality. This comes out with respect to interfaces and traits in that only errors had to be changed (for clarity) on interfaces and no changes to traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function body myself within zend_do_end_accessor_declaration(). One point of contention here is that internally it defines a __$Hours property which would be accessible from various points. I believe the standard C# get/set does not allow any access to the underlying data storage. In order to accomplish that there would need to be some non-standard storage or a super-private level or something. I did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementationhi Clint!
Thanks for your work so far!
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the voting phase. There is no need to hurry as the next release where this patch could go in is next year.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
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);Standard __get()/__set() functionality checks for the more specifically defined function name and calls them. I thought this would make the most sense since it would allow us to leverage the existing inheritance functionality. This comes out with respect to interfaces and traits in that only errors had to be changed (for clarity) on interfaces and no changes to traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function body myself within zend_do_end_accessor_declaration(). One point of contention here is that internally it defines a __$Hours property which would be accessible from various points. I believe the standard C# get/set does not allow any access to the underlying data storage. In order to accomplish that there would need to be some non-standard storage or a super-private level or something. I did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementationhi Clint!
Thanks for your work so far!
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the voting phase. There is no need to hurry as the next release where this patch could go in is next year.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
I've fixed the zend_compile.c and zend_object_handlers.c to build with
--enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage
instead of TSRMLS_CC)
Other thing I have noticed that you have not followed our coding
standards about brackets and comments (we don't use the C++ style
one). And about the comments looks as the patch isn't finished or you
just forgot the remove them?
http://dpaste.com/665851/plain/
--
Regards,
Felipe Pena
2011/12/4 Felipe Pena felipensp@gmail.com:
Hi,
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);Standard __get()/__set() functionality checks for the more specifically defined function name and calls them. I thought this would make the most sense since it would allow us to leverage the existing inheritance functionality. This comes out with respect to interfaces and traits in that only errors had to be changed (for clarity) on interfaces and no changes to traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function body myself within zend_do_end_accessor_declaration(). One point of contention here is that internally it defines a __$Hours property which would be accessible from various points. I believe the standard C# get/set does not allow any access to the underlying data storage. In order to accomplish that there would need to be some non-standard storage or a super-private level or something. I did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementationhi Clint!
Thanks for your work so far!
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the voting phase. There is no need to hurry as the next release where this patch could go in is next year.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
I've fixed the zend_compile.c and zend_object_handlers.c to build with
--enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage
instead of TSRMLS_CC)
Other thing I have noticed that you have not followed our coding
standards about brackets and comments (we don't use the C++ style
one). And about the comments looks as the patch isn't finished or you
just forgot the remove them?http://dpaste.com/665851/plain/
--
Regards,
Felipe Pena
Check out also the failing tests in Zend/tests/* (including segmentation fault)
--
Regards,
Felipe Pena
Ignore this patch for now, I'll get these issues addressed and I also want to improve the performance a bit.
Felipe, I'll check out those failing tests, I found the CODING_STANDARDS doc and will read it.
With regards to performance, I'm creating the __getHours string on each invocation. I see that Hours has the zend_literal value. What would be the best place to cache the hash_value for future calls?
Alternatively, what about adding a get/set function pointer to the property to avoid string manipulation/hash calculation? Only issue I see is larger (much larger?) memory footprint for storing two additional pointers for every class property?
-Clint
-----Original Message-----
From: Felipe Pena [mailto:felipensp@gmail.com]
Sent: Sunday, December 04, 2011 10:05 AM
To: Clint M Priest
Cc: Pierre Joye; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
2011/12/4 Felipe Pena felipensp@gmail.com:
Hi,
2011/12/4 Clint M Priest cpriest@zerocue.com:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patchIn 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);Standard __get()/__set() functionality checks for the more specifically defined function name and calls them. I thought this would make the most sense since it would allow us to leverage the existing inheritance functionality. This comes out with respect to interfaces and traits in that only errors had to be changed (for clarity) on interfaces and no changes to traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function body myself within zend_do_end_accessor_declaration(). One point of contention here is that internally it defines a __$Hours property which would be accessible from various points. I believe the standard C# get/set does not allow any access to the underlying data storage. In order to accomplish that there would need to be some non-standard storage or a super-private level or something. I did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementationhi Clint!
Thanks for your work so far!
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the voting phase. There is no need to hurry as the next release where this patch could go in is next year.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
To unsubscribe,
visit: http://www.php.net/unsub.phpI've fixed the zend_compile.c and zend_object_handlers.c to build with
--enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage
instead of TSRMLS_CC) Other thing I have noticed that you have not
followed our coding standards about brackets and comments (we don't
use the C++ style one). And about the comments looks as the patch
isn't finished or you just forgot the remove them?http://dpaste.com/665851/plain/
--
Regards,
Felipe Pena
Check out also the failing tests in Zend/tests/* (including segmentation fault)
--
Regards,
Felipe Pena
hi,
Please attach the patch (and any future version) to the RFC and to
https://bugs.php.net/bug.php?id=49526, so it won't be lost if your
sever goes down.
Thanks!
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org