Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Dmitry Stogov wrote: Hi, Personally, I like the patch except for some small possible tweaks, and I believe it can't make any harm with lazy loading disabled. Thanks, what are the tweaks you'd like to see so I can try to include them? Could you provide some benchmark results? I was hoping to solicit some from others on the list, but haven't seen anything yet. My best example of gains is Facebook, I believe these where around 20-30% decrease in CPU usage on a bare-bones page. I did test Joomla and Zend Framework, the gains here aren't much if anything as they seem to be use autoload for most files. (although I would like to see what lazy method loading can do here). I intend to benchmark wordpress as well. I'll post more benchmarks for the above and this once I make some more tweaks that also might give us better results. I anticipate that benchmarks are going to vary pretty drastically depending on code structure, size, autoloading, etc. APC patch to play with it and see advantages/disadvantages? I've gone ahead and checked in the current code for APC, so you'll have the necessary changes if you checkout CVS HEAD. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
shire wrote: Dmitry Stogov wrote: Hi, Personally, I like the patch except for some small possible tweaks, and I believe it can't make any harm with lazy loading disabled. Thanks, what are the tweaks you'd like to see so I can try to include them? I thought about different semantics for defined_function_hook and declared_class_hook to just load all lazy function/classes into regular ZE tables. It's also possible to pass hash_values into lookup_function_hook and lookup_class_hook to don't calculate them twice. I'll return to you in a day or two (after playing with patch and measuring speed difference) to be more concrete. Thanks. Dmitry. Could you provide some benchmark results? I was hoping to solicit some from others on the list, but haven't seen anything yet. My best example of gains is Facebook, I believe these where around 20-30% decrease in CPU usage on a bare-bones page. I did test Joomla and Zend Framework, the gains here aren't much if anything as they seem to be use autoload for most files. (although I would like to see what lazy method loading can do here). I intend to benchmark wordpress as well. I'll post more benchmarks for the above and this once I make some more tweaks that also might give us better results. I anticipate that benchmarks are going to vary pretty drastically depending on code structure, size, autoloading, etc. APC patch to play with it and see advantages/disadvantages? I've gone ahead and checked in the current code for APC, so you'll have the necessary changes if you checkout CVS HEAD. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing build configuration acinclude.m4
Christopher Jones wrote: Does anyone (where's Jani?) want to comment on updating (*) the definition of PHP_SHLIB_SUFFIX_NAMES in acinclude.m4? I don't want to comment on stuff I don't use.. :) (I don't do HP-UX) The PHP_SHLIB_SUFFIX_NAMES macro is very simplistic in setting the SHLIB_SUFFIX_NAME shared lib file extension. In comparison, the AC_LIBTOOL_SYS_DYNAMIC_LINKER macro in build/libtool.m4 is more finegrained, in particular in differentiating between HP-UX Itanium and HP-UX PA RISC. The base problem was reported for the OCI8 extension in http://pecl.php.net/bugs/bug.php?id=15016 An untested patch for acinclude.m4 is: --- acinclude.m4.orig2008-12-03 13:55:53.0 -0800 +++ acinclude.m42009-03-10 13:57:10.0 -0700 @@ -1975,8 +1975,16 @@ SHLIB_DL_SUFFIX_NAME=$SHLIB_SUFFIX_NAME case $host_alias in *hpux*[)] - SHLIB_SUFFIX_NAME=sl - SHLIB_DL_SUFFIX_NAME=sl + case $host_cpu in + ia64*[)] + SHLIB_SUFFIX_NAME=so + SHLIB_DL_SUFFIX_NAME=so + ;; + *[)] + SHLIB_SUFFIX_NAME=sl + SHLIB_DL_SUFFIX_NAME=sl + ;; + esac ;; *darwin*[)] SHLIB_SUFFIX_NAME=dylib Is $host_cpu appropriately set at this point of configuration? Try it? If it works, commit. Is there a reason why PHP_SHLIB_SUFFIX_NAMES doesn't use AC_LIBTOOL_SYS_DYNAMIC_LINKER? Because nobody knew that exists? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Hi Shire, I run patched APC on a number of real-life applications and got more than 30% speedup on XOOPS (99 req/sec instead of 60%) and 20% on ZendFramework (41 req/sec instead of 32), however most applications (drupal, qdig, typo3, wordpress) didn't show significant speed difference. As was expected the patch doesn't affects PHP without APC or with APC and lazy loading disabled. I also got APC warning with Zend Framewoek based blog application, but I didn't try to look deeper. [Wed Mar 11 17:53:02 2009] [apc-warning] [Wed Mar 11 17:53:02 2009] [apc-warning] apc_lookup_class_hook: could not install blogrow in /var/www/html/bench/fw/ZendFramework-1.5.0RC3/library/Zend/Loader.php on line 86 I didn't look careful into APC code, just into PHP patch and I see the following issues: 1) I would prefer to add additional hash_value argument into lookup_function_hook() and lookup_class_hook to prevent multiple calculation. 2) function_exists() should use lookup_function_hook(). 3) interface_exists() and class_alias() should use lookup_class_hook(). 4) ext/soap, ext/reflection, ext/wddx and ext/spl autoload support Anyway, it's very good job and 20-30% speedup on some real-life applications makes sense to include it into 5.3 (from my point of view). Thanks. Dmitry. shire wrote: Dmitry Stogov wrote: Hi, Personally, I like the patch except for some small possible tweaks, and I believe it can't make any harm with lazy loading disabled. Thanks, what are the tweaks you'd like to see so I can try to include them? Could you provide some benchmark results? I was hoping to solicit some from others on the list, but haven't seen anything yet. My best example of gains is Facebook, I believe these where around 20-30% decrease in CPU usage on a bare-bones page. I did test Joomla and Zend Framework, the gains here aren't much if anything as they seem to be use autoload for most files. (although I would like to see what lazy method loading can do here). I intend to benchmark wordpress as well. I'll post more benchmarks for the above and this once I make some more tweaks that also might give us better results. I anticipate that benchmarks are going to vary pretty drastically depending on code structure, size, autoloading, etc. APC patch to play with it and see advantages/disadvantages? I've gone ahead and checked in the current code for APC, so you'll have the necessary changes if you checkout CVS HEAD. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Dmitry Stogov wrote: Hi Shire, I run patched APC on a number of real-life applications and got more than 30% speedup on XOOPS (99 req/sec instead of 60%) and 20% on ZendFramework (41 req/sec instead of 32), however most applications (drupal, qdig, typo3, wordpress) didn't show significant speed difference. As was expected the patch doesn't affects PHP without APC or with APC and lazy loading disabled. I also got APC warning with Zend Framewoek based blog application, but I didn't try to look deeper. [Wed Mar 11 17:53:02 2009] [apc-warning] [Wed Mar 11 17:53:02 2009] [apc-warning] apc_lookup_class_hook: could not install blogrow in /var/www/html/bench/fw/ZendFramework-1.5.0RC3/library/Zend/Loader.php on line 86 I didn't look careful into APC code, just into PHP patch and I see the following issues: 1) I would prefer to add additional hash_value argument into lookup_function_hook() and lookup_class_hook to prevent multiple calculation. 2) function_exists() should use lookup_function_hook(). 3) interface_exists() and class_alias() should use lookup_class_hook(). 4) ext/soap, ext/reflection, ext/wddx and ext/spl autoload support Anyway, it's very good job and 20-30% speedup on some real-life applications makes sense to include it into 5.3 (from my point of view). Makes sense to me as well, especially since I don't see any drawbacks for non-accelerated scripts. I also think some of those applications that didn't show any gains could be trivially modified to make use of it. Moving from conditionally loaded stuff to lazy-loaded is likely to speed things up. Depending of course on how granular the conditional loading is. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 11.03.2009, at 17:10, Rasmus Lerdorf wrote: Anyway, it's very good job and 20-30% speedup on some real-life applications makes sense to include it into 5.3 (from my point of view). Makes sense to me as well, especially since I don't see any drawbacks for non-accelerated scripts. I also think some of those applications that didn't show any gains could be trivially modified to make use of it. Moving from conditionally loaded stuff to lazy-loaded is likely to speed things up. Depending of course on how granular the conditional loading is. Can we get this patch to release quality by this weekend? So that people can test it on Monday/Tuesday ahead of RC1? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Lukas Kahwe Smith wrote: On 11.03.2009, at 17:10, Rasmus Lerdorf wrote: Anyway, it's very good job and 20-30% speedup on some real-life applications makes sense to include it into 5.3 (from my point of view). Makes sense to me as well, especially since I don't see any drawbacks for non-accelerated scripts. I also think some of those applications that didn't show any gains could be trivially modified to make use of it. Moving from conditionally loaded stuff to lazy-loaded is likely to speed things up. Depending of course on how granular the conditional loading is. Can we get this patch to release quality by this weekend? I think it's possible. I could help with it. Thanks. Dmitry. So that people can test it on Monday/Tuesday ahead of RC1? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing build configuration acinclude.m4
Jani Taskinen wrote: Christopher Jones wrote: Does anyone (where's Jani?) want to comment on updating (*) the definition of PHP_SHLIB_SUFFIX_NAMES in acinclude.m4? I don't want to comment on stuff I don't use.. :) (I don't do HP-UX) Ditto The PHP_SHLIB_SUFFIX_NAMES macro is very simplistic in setting the SHLIB_SUFFIX_NAME shared lib file extension. In comparison, the AC_LIBTOOL_SYS_DYNAMIC_LINKER macro in build/libtool.m4 is more finegrained, in particular in differentiating between HP-UX Itanium and HP-UX PA RISC. The base problem was reported for the OCI8 extension in http://pecl.php.net/bugs/bug.php?id=15016 An untested patch for acinclude.m4 is: --- acinclude.m4.orig2008-12-03 13:55:53.0 -0800 +++ acinclude.m42009-03-10 13:57:10.0 -0700 @@ -1975,8 +1975,16 @@ SHLIB_DL_SUFFIX_NAME=$SHLIB_SUFFIX_NAME case $host_alias in *hpux*[)] - SHLIB_SUFFIX_NAME=sl - SHLIB_DL_SUFFIX_NAME=sl + case $host_cpu in + ia64*[)] + SHLIB_SUFFIX_NAME=so + SHLIB_DL_SUFFIX_NAME=so + ;; + *[)] + SHLIB_SUFFIX_NAME=sl + SHLIB_DL_SUFFIX_NAME=sl + ;; + esac ;; *darwin*[)] SHLIB_SUFFIX_NAME=dylib Is $host_cpu appropriately set at this point of configuration? Try it? If it works, commit. OK! We'll see if the bug filer responds. Is there a reason why PHP_SHLIB_SUFFIX_NAMES doesn't use AC_LIBTOOL_SYS_DYNAMIC_LINKER? Because nobody knew that exists? :) :) Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Hello Lukas, Wednesday, March 11, 2009, 5:10:57 PM, you wrote: Dmitry Stogov wrote: Hi Shire, I run patched APC on a number of real-life applications and got more than 30% speedup on XOOPS (99 req/sec instead of 60%) and 20% on ZendFramework (41 req/sec instead of 32), however most applications (drupal, qdig, typo3, wordpress) didn't show significant speed difference. As was expected the patch doesn't affects PHP without APC or with APC and lazy loading disabled. I also got APC warning with Zend Framewoek based blog application, but I didn't try to look deeper. [Wed Mar 11 17:53:02 2009] [apc-warning] [Wed Mar 11 17:53:02 2009] [apc-warning] apc_lookup_class_hook: could not install blogrow in /var/www/html/bench/fw/ZendFramework-1.5.0RC3/library/Zend/Loader.php on line 86 I didn't look careful into APC code, just into PHP patch and I see the following issues: 1) I would prefer to add additional hash_value argument into lookup_function_hook() and lookup_class_hook to prevent multiple calculation. 2) function_exists() should use lookup_function_hook(). 3) interface_exists() and class_alias() should use lookup_class_hook(). 4) ext/soap, ext/reflection, ext/wddx and ext/spl autoload support Anyway, it's very good job and 20-30% speedup on some real-life applications makes sense to include it into 5.3 (from my point of view). Makes sense to me as well, especially since I don't see any drawbacks for non-accelerated scripts. I also think some of those applications that didn't show any gains could be trivially modified to make use of it. Moving from conditionally loaded stuff to lazy-loaded is likely to speed things up. Depending of course on how granular the conditional loading is. Right, basically the patch adresses what we say at conferences. Autload can do an amazing job but also harm you. The patch on the other hand somehow combines the advantages of both worlds. You can be explicit because you know it better and for that you do not get any punishment from Autoload execution time. And then again, you don't get punished by including too much. Becuase after all the compiler knows it even better. And of course, given that some people gain over 20%, I don't see why we even need to discuss putting this in. Last but not least, Lukas, what happened, to putting APC into core? marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch and test cases too for
I think this behavior is a bit odd too:
php -r echo json_encode(array(0='test')); // [test]
php -r echo json_encode(array(1='test')); // {1:test}
On Tue, Mar 10, 2009 at 11:32 AM, Richard Quadling rquadl...@googlemail.com
wrote:
2009/3/2 Scott MacVicar sc...@macvicar.net:
Richard Quadling wrote:
2009/3/2 Scott MacVicar sc...@macvicar.net:
Richard Quadling wrote:
Hi.
Regarding http://bugs.php.net/bug.php?id=47493, I've supplied a patch
to the unit tests too.
Any chance this could get committed to 5.2+
I'm too convinced of the parameter name and I don't think its something
that should be added to 5.2.9 since its a feature.
Scott
5.3+ would be OK then.
As to the param name, I'm not actually changing the name, just adding
another flag.
In javascript's terminology,the output is an array ...
[]
or a hash
{}
So forcing a hash for arrays is pretty much what would be wanted and I
as I comment in the request, we have a force option when coming FROM
json data ... json_decode ( string $json [, bool $assoc= false [, int
$depth= 512 ]] )
And the name of the param here is appropriate to PHP's use (assoc is
not part of JSON's or JS's terminology).
If you can think of a better name for the flag, then I'd be glad to use
it.
The JSON spec refers to them as arrays or objects though, as does our
documentation I believe.
PHP_JSON_FORCE_OBJECT
I however have another patch for more strict encoding so I'll try to
roll this in a single update.
Scott
First of all, this isn't a why is this not done yet message. Honestly.
Do you have any timeframe for this though?
Do you think it will be ready for 5.3RC1?
Thank you,
Richard Quadling.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch and test cases too for
2009/3/11 Christopher Östlund christopher.oestl...@gmail.com:
I think this behavior is a bit odd too:
php -r echo json_encode(array(0='test')); // [test]
php -r echo json_encode(array(1='test')); // {1:test}
And
php -r echo json_encode(array(0='test',3='foo')); // {0:test,3:foo}
So it seems that zero-base, sequential, integer indexed arrays will be
output as a JS array and any other type of array will be an object
hash. The PHP_JSON_FORCE_OBJECT (thank you Scott for the name) would
at least clarify the output for dynamically created output.
On Tue, Mar 10, 2009 at 11:32 AM, Richard Quadling rquadl...@googlemail.com
wrote:
2009/3/2 Scott MacVicar sc...@macvicar.net:
Richard Quadling wrote:
2009/3/2 Scott MacVicar sc...@macvicar.net:
Richard Quadling wrote:
Hi.
Regarding http://bugs.php.net/bug.php?id=47493, I've supplied a patch
to the unit tests too.
Any chance this could get committed to 5.2+
I'm too convinced of the parameter name and I don't think its something
that should be added to 5.2.9 since its a feature.
Scott
5.3+ would be OK then.
As to the param name, I'm not actually changing the name, just adding
another flag.
In javascript's terminology,the output is an array ...
[]
or a hash
{}
So forcing a hash for arrays is pretty much what would be wanted and I
as I comment in the request, we have a force option when coming FROM
json data ... json_decode ( string $json [, bool $assoc= false [, int
$depth= 512 ]] )
And the name of the param here is appropriate to PHP's use (assoc is
not part of JSON's or JS's terminology).
If you can think of a better name for the flag, then I'd be glad to use
it.
The JSON spec refers to them as arrays or objects though, as does our
documentation I believe.
PHP_JSON_FORCE_OBJECT
I however have another patch for more strict encoding so I'll try to
roll this in a single update.
Scott
First of all, this isn't a why is this not done yet message. Honestly.
Do you have any timeframe for this though?
Do you think it will be ready for 5.3RC1?
Thank you,
Richard Quadling.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Lukas Kahwe Smith wrote: Can we get this patch to release quality by this weekend? So that people can test it on Monday/Tuesday ahead of RC1? I don't see this being a problem, I do have a few items I'd like to point out for feedback/suggestions: 1) Currently it doesn't support method level lazy loading, it's probably advisable to wait and include this later, but if everyone thinks it's significant enough we could probably add support for that. I'm not sure on all the details this involves, perhaps someone familiar with method calls could suggest difficulty and/or optimized ways to do the lookups. 2) Currently I've inserted these hook calls into everywhere we call/lookup classes. This has the downside that any extension wanting to mess with the function table, lookup entries, etc will need to be aware of the callback hooks. I think a better architecture is to create an API for function table and class table operations. Perhaps this could be done later if we want this likely more stable version in 5.3, and perhaps I'm overstating the significance of other functions doing these sort of things and not being aware of this new feature. (I believe dmitry mentions several extenions that need changes to support this). On the upside not creating an API means existing code will still work if they don't use lazy loading. ;-) 3) The largest portion of time currently is simply adding dummy entries to the lazy hash tables so we can detect name collisions and availability, my next goal is to improve the performance of this by either creating a faster copy of the entries or determine some better method of performing lookups/marking functions as available (something like lookups directly into the APC shared memory segment). Just putting this out there in case anyone has some interesting suggestions. I think all the above 3 items don't necessarily need to be done to have this work in 5.3 (and #3 is pretty much APC/opcode cache centric) and might cause unecessary complication for an initial support of this, but what does everyone else think? Regarding a couple of Dmitry's suggestions: 1) I would prefer to add additional hash_value argument into lookup_function_hook() and lookup_class_hook to prevent multiple calculation. I'm upset I didn't do that in the first place ;-) 2) function_exists() should use lookup_function_hook(). 3) interface_exists() and class_alias() should use lookup_class_hook(). I'm pretty sure I already have support for this, it may have been lost while porting it over, I'll double check. I'll follow up with Dmitry on getting these and any other items taken care of, thanks! -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Questions on closures and visibility
Hi all,
Since around alpha1, I've been doing some experimenting with closures,
most recently in the form of a filter chain implementation, and I've
discovered that as of beta1 (as was noted in the removal-of-$this
RFC) that there is no way to access private or protected members of
any class inside a closure, regardless of where it is defined.
I realize that the question of implicit $this support for closures has
already been discussed and decided upon temporarily (and I certainly
have no wish to rehash it again), however, it seems logical that even
without being bound to an object, closures should still inherit the
scope in which they're defined. Otherwise, this creates a confusing
inconsistency within the language. Consider the following:
class Exposed {
private $_property;
public function __construct($data = null) {
$this-_property = $data;
}
public function getProtected($self, $property) {
return $self-$property;
}
}
$object1 = new Exposed('secret');
$object2 = new Exposed();
// successfully echos secret
echo $object2-getProtected($object1, '_property'));
Because of PHP's scope and visibility rules, this works even though
$object1 and $object2 are only associated by common parentage. While
this may have no technical significance, since a closure is actually
it's own class, in practical terms it puts a damper on the usefulness
of the implementation, and is a bit of a WTF, particularly when
considered in context with use, which allows closures to inherit and
even modify variables in the declaring scope, regardless of where they
are called.
Again, to clarify, I am not arguing for $this support to be added back
to closures (though if a consensus could be reached before 5.3 final,
that'd be great, too :-)). I am simply suggesting that the current
implementation might be improved and made more consistent (without
designing it into a corner concerning future decisions) by allowing a
closure defined in class X to follow the same rules as any other
method also defined in X.
Any thoughts or feedback would be very much appreciated. :-)
Thanks for your time and consideration,
- Nate Abele
Lead Developer, CakePHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions on closures and visibility
Hi Nate, Any thoughts or feedback would be very much appreciated. :-) The scoping problem is very deeply related to the $this issue: Should one be able to switch the change of a closure by re-binding it to another object or not? It was also an open point in my RFC on object extension in general - which describes the different approaches to $this and scoping and the reason why we have do decide BEFORE adding support for that which way we want it since otherwise we don't be able to change the behaviour later on if we decide against it. So, it may be a small WTF that the scope is not inherited at all. But if we re-add support for that, useful as it may be, there will be no possibility of changing that in the future - and since the scope is deeply related to $this, it could be that the then chosen solution for $this is also incompatible with the scoping version we choose now. When I reverted OOP support for beta 1, I carefully made sure that the current implementation in PHP 5.3 is done in such a way that OOP support may be added later on without dictating which type of OOP support it will be. Any change to that would limit future choices. And since nobody here actually continued the OOP - Closure discussion for post-5.3 after my revert in beta 1, I don't think that discussion will have progressed far enough for RC 1 that re-adding scoping behaviour would be a wise idea. Regards, Christian Just FYI: My stance on the issue hasn't changed, I'm still in favor of the original behaviour Dmitry and I designed + addition of bindTo () for dynamic object extension, see: http://wiki.php.net/rfc/closures/object-extension -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] non static function called as static one
Hello,
I posted the same topic on the general mailing list, but it appears this can
be posted here, as it is open to feedbacks and is about PHP implementation
of static functions.
I'm wondering if the following behaviour is a bug or a feature. The case is
quite complex, so let me explain my point of view.
here is the source :
?php
class MyTest {
public function myfunc() {
echo get_class($this);
}
}
class MySecondTest {
public function test() {
MyTest::myfunc();
}
}
$test = new MySecondTest();
$test-test(); //output: MySecondTest
?
In this case, $this is MySecondTest, which is relevant as it is the last
object context. But to my mind, this code should not work like this.
Imagine you are the developer of function MyTest. You want your code to
interact with other classes and being bugproof. 'MyTest' class here seems
OK: $this is expected to be 'MyTest' because function myfunc() is expected
to be called in a non-static context.
Programmer of the second function created this bug and this unattended
behaviour.
Maybe this can be done :
1/ Forbid calling the function in static context (How can I test this ?
$this is not NULL there !).
2/ (or/and) Raise an error if a non static function is called as a static
one (if E_STRICT is set, strict warning is already raised).
3/ Create two functions with the same name, one static and the other one
not. Unfortunately, this can't be done (yet ?).
What do you think ? What's your point of view on this ? I want your
feedbacks before opening a bug ticket, as it is not strictly a bug...
Re: [PHP-DEV] non static function called as static one
On Wed, 2009-03-11 at 22:16 +0100, Olivier Doucet wrote:
Hello,
I posted the same topic on the general mailing list, but it appears this can
be posted here, as it is open to feedbacks and is about PHP implementation
of static functions.
I'm wondering if the following behaviour is a bug or a feature. The case is
quite complex, so let me explain my point of view.
here is the source :
?php
class MyTest {
public function myfunc() {
echo get_class($this);
}
}
class MySecondTest {
public function test() {
MyTest::myfunc();
}
}
$test = new MySecondTest();
$test-test(); //output: MySecondTest
?
In this case, $this is MySecondTest, which is relevant as it is the last
object context. But to my mind, this code should not work like this.
Imagine you are the developer of function MyTest. You want your code to
interact with other classes and being bugproof. 'MyTest' class here seems
OK: $this is expected to be 'MyTest' because function myfunc() is expected
to be called in a non-static context.
Programmer of the second function created this bug and this unattended
behaviour.
Maybe this can be done :
1/ Forbid calling the function in static context (How can I test this ?
$this is not NULL there !).
2/ (or/and) Raise an error if a non static function is called as a static
one (if E_STRICT is set, strict warning is already raised).
3/ Create two functions with the same name, one static and the other one
not. Unfortunately, this can't be done (yet ?).
What do you think ? What's your point of view on this ? I want your
feedbacks before opening a bug ticket, as it is not strictly a bug...
Comments from a lurker...
For better or worse, it's been well documented that what you are
describing is php's behavior and it would be an enormous backwards
compatibility break to change it. Consider the following example, in
which two generally unrelated class heirarchies have enough in common
somewhere in the tree that some would be inclined to use multiple
inheritance:
?php
class ABase {
public $a;
}
class A extends ABase {
public $x;
function f() {
HelpsAandB::f();
}
}
class BBase {
public $b;
}
class B extends BBase {
public $x;
function f() {
HelpsAandB::f();
}
}
class HelpsAandB {
function f() {
var_dump($this-x);
}
}
$example = new A;
$example-x = 5;
$example-f();
?
Is that a messed up design? Almost certainly. Is it a nightmare to
re-design/re-implement many tens of thousands of lines of code that rely
on such behavior? Unfortunately, that's true also. (You may have
guessed that I'm responsible for such code and most of it was written
before I joined the company.)
I like to think this rules out options 1 and 2. I'm not sure about
option 3.
Maybe there could be a function that returns whether the current
function call is associated with the current object (ie whether it was
called via :: or -). I'm not an internals expert.
Maybe to address backwards compatibility and address the concern you
raise, there could be a nonstatic keyword. php would throw an error
if a function declared nonstatic is called using ::.
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] non static function called as static one
On Wed, Mar 11, 2009 at 3:16 PM, Olivier Doucet webmas...@ajeux.com wrote:
Hello,
I posted the same topic on the general mailing list, but it appears this
can
be posted here, as it is open to feedbacks and is about PHP implementation
of static functions.
I'm wondering if the following behaviour is a bug or a feature. The case is
quite complex, so let me explain my point of view.
here is the source :
?php
class MyTest {
public function myfunc() {
echo get_class($this);
}
}
class MySecondTest {
public function test() {
MyTest::myfunc();
}
}
$test = new MySecondTest();
$test-test(); //output: MySecondTest
?
not sure if this was mentioned on the general list but, i believe what youre
describing is documented in the manual under php5 classes/objects - the
basics:
http://www.php.net/manual/en/language.oop5.basic.php
$this is a reference to the calling object (usually the object to which the
method belongs, but can be another object, if the method is called
statically http://www.php.net/manual/en/language.oop5.static.php from the
context of a secondary object).
-nathan
Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 11.03.2009, at 19:55, Marcus Boerger wrote: Last but not least, Lukas, what happened, to putting APC into core? That was planned for PHP 6.0. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 TODO list
Hi everyone, I've been cleaning up the TODO items on the Wiki. I created a Backlog section and moved all the items from PHP 5.3/Future PHP releases and PHP 6/Undiscussed to it. This will serve as a general repository for any items that have been mentioned, but on which we have not made a decision yet. Items that have been decided on should go into the corresponding version's section. Also, please go through PHP 6 section [http://wiki.php.net/todo/php60] and remove or update any items that have been done or the scope of which has changed. Thanks, -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 items
shire wrote: Hey Lukas, Just a heads up that I should have a fix for this soonish, just running some more tests to make sure everything works as expected (I assume nobody else has started work on this): 9. tokenizer misses last single-line comment (http://bugs.php.net/bug.php?id=46817) Ok, just checked this in, let me know if I missed anything or if there's any issues. I noticed that CVS HEAD seemed to have dos line feeds and some other bad merge stuff so those where fixed as a side affect of my commit. This should also correct some highlighting bugs that were introduced (see the fix to the highlight_file test). -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Hello Lukas, Wednesday, March 11, 2009, 11:15:23 PM, you wrote: On 11.03.2009, at 19:55, Marcus Boerger wrote: Last but not least, Lukas, what happened, to putting APC into core? That was planned for PHP 6.0. there is no such thing. Let's either do it now or go for 5.4. regards, Lukas Kahwe Smith m...@pooteeweet.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions on closures and visibility
Hello Nate, Wednesday, March 11, 2009, 9:25:23 PM, you wrote: Hi all, Since around alpha1, I've been doing some experimenting with closures, most recently in the form of a filter chain implementation, and I've discovered that as of beta1 (as was noted in the removal-of-$this RFC) that there is no way to access private or protected members of any class inside a closure, regardless of where it is defined. I realize that the question of implicit $this support for closures has already been discussed and decided upon temporarily (and I certainly have no wish to rehash it again), however, it seems logical that even without being bound to an object, closures should still inherit the scope in which they're defined. Otherwise, this creates a confusing inconsistency within the language. At the moment it simply is impossible to allow $this. Simply becasue we could not solve resolving it correctly, or figuring out the scope correctly. An attempt of mine to solve the issues first looked good and then just brought up more issues and the only way to solve them was to make everything slower. So we decided to keep closures as external entities that are not bound to the scope they are created in. In the same way we do not bind anythign magically. Also it appears that you probably want a real callback if you ave to access private or protected members. At least from a pure design stanpoint that is more than obvious. Please leave it for the moment, we are far to close in PHP 5.3 release process to do somethign about it now. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] non static function called as static one
Hi, not sure if this was mentioned on the general list but, i believe what youre describing is documented in the manual under php5 classes/objects - the basics: http://www.php.net/manual/en/language.oop5.basic.php $this is a reference to the calling object (usually the object to which the method belongs, but can be another object, if the method is called statically http://www.php.net/manual/en/language.oop5.static.php from the context of a secondary object). -nathan I know this behaviour is fully documented, but I was more concerned about is it a 'normal' behaviour ?. How can a programmer controls the class he wrote, and make it absolutely bugproof ? How can he detect his function was called in a static context and forbid it (or write specific code for) ? Olivier
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Hi! there is no such thing. Let's either do it now or go for 5.4. Can we please stop trying new big features each time we approach RC? 5.3 is not last PHP version ever, and it's long overdue. Can't we just release it without putting more and more potentially unstable changes into it, and then discuss other stuff for 5.4, 6.0 and whatever comes in orderly manner? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 11.03.2009, at 20:58, shire wrote: Lukas Kahwe Smith wrote: Can we get this patch to release quality by this weekend? So that people can test it on Monday/Tuesday ahead of RC1? I don't see this being a problem, I do have a few items I'd like to point out for feedback/suggestions: 1) Currently it doesn't support method level lazy loading, it's probably advisable to wait and include this later, but if everyone thinks it's significant enough we could probably add support for that. I'm not sure on all the details this involves, perhaps someone familiar with method calls could suggest difficulty and/or optimized ways to do the lookups. 2) Currently I've inserted these hook calls into everywhere we call/ lookup classes. This has the downside that any extension wanting to mess with the function table, lookup entries, etc will need to be aware of the callback hooks. I think a better architecture is to create an API for function table and class table operations. Perhaps this could be done later if we want this likely more stable version in 5.3, and perhaps I'm overstating the significance of other functions doing these sort of things and not being aware of this new feature. (I believe dmitry mentions several extenions that need changes to support this). On the upside not creating an API means existing code will still work if they don't use lazy loading. ;-) 3) The largest portion of time currently is simply adding dummy entries to the lazy hash tables so we can detect name collisions and availability, my next goal is to improve the performance of this by either creating a faster copy of the entries or determine some better method of performing lookups/marking functions as available (something like lookups directly into the APC shared memory segment). Just putting this out there in case anyone has some interesting suggestions. I think all the above 3 items don't necessarily need to be done to have this work in 5.3 (and #3 is pretty much APC/opcode cache centric) and might cause unecessary complication for an initial support of this, but what does everyone else think? Hmm, thanks for your open assessment here. What you are saying does make me wonder if we really should push this into 5.3. Even if any changes we need to do can eventually be handled by APC, I do think that there will be other extension authors that would also suffer from us messing around with these internals all too much in every release. So maybe we should wait until the next bigger step before introducing this. Other people can apply the patch themselves if they really need the performance in the mean time .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] non static function called as static one
On Wed, Mar 11, 2009 at 4:40 PM, Olivier Doucet webmas...@ajeux.com wrote:
Hi,
not sure if this was mentioned on the general list but, i believe what
youre describing is documented in the manual under php5 classes/objects -
the basics:
http://www.php.net/manual/en/language.oop5.basic.php
$this is a reference to the calling object (usually the object to which
the method belongs, but can be another object, if the method is called
statically http://www.php.net/manual/en/language.oop5.static.php from
the context of a secondary object).
-nathan
I know this behaviour is fully documented, but I was more concerned about
is it a 'normal' behaviour ?. How can a programmer controls the class he
wrote, and make it absolutely bugproof ? How can he detect his function was
called in a static context and forbid it (or write specific code for) ?
well, the access to $this of the secondary object is limited. so the only
way it really does anything useful is if member variables you wish to access
are marked as public; making it mostly useless imo.. but anyway all youd
need to do is mark member vars as protected or private. (personally, i think
it should be able to access protected vars, since the class which invokes
the other statically is essentially sanctioning access to its instance
variables).
?php
class A {
public function showOtherClassInstanceVar($varname) {
var_dump($this-$varname);
}
}
class B {
public $a = 1;
protected $b = 2;
private $c = 3;
public function dumpViaMixin() {
A::showOtherClassInstanceVar('a');
A::showOtherClassInstanceVar('b');
A::showOtherClassInstanceVar('c');
}
}
$b = new B();
$b-dumpViaMixin();
---
outputs
int(1)
then the error log shows,
[11-Mar-2009 17:01:03] PHP Fatal error: Cannot access protected property
B::$b in /Users/nnobbe/testDelegation.php on line 5
[11-Mar-2009 17:01:03] PHP Stack trace:
[11-Mar-2009 17:01:03] PHP 1. {main}() /Users/nnobbe/testDelegation.php:0
[11-Mar-2009 17:01:03] PHP 2. B-dumpViaMixin()
/Users/nnobbe/testDelegation.php:22
[11-Mar-2009 17:01:03] PHP 3. A-showOtherClassInstanceVar()
/Users/nnobbe/testDelegation.php:16
so you should be able to protect your classes w/o too much trouble.
-nathan
Re: [PHP-DEV] non static function called as static one
Olivier Doucet wrote: Hi, not sure if this was mentioned on the general list but, i believe what youre describing is documented in the manual under php5 classes/objects - the basics: http://www.php.net/manual/en/language.oop5.basic.php $this is a reference to the calling object (usually the object to which the method belongs, but can be another object, if the method is called statically http://www.php.net/manual/en/language.oop5.static.php from the context of a secondary object). -nathan I know this behaviour is fully documented, but I was more concerned about is it a 'normal' behaviour ?. How can a programmer controls the class he Yes wrote, and make it absolutely bugproof ? How can he detect his function was called in a static context and forbid it (or write specific code for) ? You can't unless you do some obtuse kind of: if (isset($this) $this instanceof MyClass) But even this results in terrible and subtle mistakes if you happen to call a static method from within a method of a subclass of MyClass. instead use static function blah() for static functions, and $this simply will not be available. Don't call non-static methods statically unless you want trouble. static was introduced precisely for this reason. Trying to make functions work as both dynamic and static is a disaster, and we have had endless intractable problems with the most prevalent implementation of this double design in the PEAR base class, specifically with PEAR::raiseError(). Just don't do it. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cloning of objects passed as parameters
Thanks Marcus,
Actually, persistence wasn't the only issue. I had to make sure that
the DOMDocument wasn't later modified, as that could lead to weird
behavior. Basically, what i needed was a way to pass an object by copy
rather than by reference, as it was in ZE1. I figured out a solution,
so I'm posting it here in case somebody stumbles on this post with the
same question I had.
ZEND_METHOD(xydelta, setStartDocument) {
zval *id, *doc = NULL;
xydelta_object *intern;
if (zend_parse_method_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
getThis(),, Oo, id, xydelta_ce, doc) == FAILURE) {
RETURN_FALSE;
}
intern = (xydelta_object *)zend_object_store_get_object(id TSRMLS_CC);
if (intern == NULL) {
RETURN_FALSE;
}
// Error checking removed for brevity...
// ...
// Clone zval* doc
zend_object_handlers *handlers = Z_OBJ_HT(doc);
zval *doc_clone;
MAKE_STD_ZVAL(doc_clone);
Z_TYPE_P(doc_clone) = IS_OBJECT;
Z_OBJVAL(doc_clone) = handlers-clone_obj(doc);
// Get cloned object
intern-libxml_start_doc = (php_libxml_node_object *)
zend_object_store_get_object(doc_clone TSRMLS_CC);
}
}
On 2009-03-10 16:03:19 -0400, he...@php.net (Marcus Boerger) said:
Hello Frankie,
DOMDocuments are reference counted, hence zou can simplz increase their
refcount when storing the connection and delete the ref when dropping the
connection, probably in your destructor.
Best regards,
Marcus
Tuesday, March 10, 2009, 5:19:32 PM, you wrote:
I'm writing a PHP class with a method that has to be passed a
DOMDocument object, and it needs to retain that object throughout the
life of its instantiation. However, the (dom_object *) returned from
zend_parse_method_parameters is just a pointer to the passed object,
and so it disappears when the original document is unset or goes out of
scope. How would one go about cloning the DOMDocument to save in the
class's struct?
example:
ZEND_METHOD(xydelta, setStartDocument) {
zval *id, *doc = NULL;
xydelta_object *intern;
if (zend_parse_method_parameters(ZEND_NUM_ARGS() TSRMLS_CC, getThis(),
Oo, id, xydelta_ce, doc) == FAILURE) {
RETURN_FALSE;
}
intern = (xydelta_object *)zend_object_store_get_object(id TSRMLS_CC);
if (intern != NULL) {
// Error checking removed for brevity...
// ...
// This pointer cannot be accessed once the object that was used as
the first parameter goes out of scope
intern-libxml_start_doc = (php_libxml_node_object *)
zend_object_store_get_object(doc TSRMLS_CC);
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
