[PHP-DEV] RC3
Anything else that needs to go into RC3? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
*This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > Anything else that needs to go into RC3? maybe not so important for *nixer, but for Windows: I have a really annoying Memory Leak here on my Dev-Station with WinXP and the latest snaps-built (from tomorrow). Every call of a php- script increases the memory-usage of apache about 3-4 MB, so that in consequence the apache takes up about 700MB memory after some reloads of a php-script. Killing this apache-process is the only way to free memory again. This behavior appears since some earlier CVS-Builts (Don't know the exact one). Sorry, that i have no more details to give, but if you tell me what to do, i would be happy to support you with finding a solution. cheers -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Use of 'self' in static function in subclass
Hi All,
I have a class and a subclass, both with a static method:
class Foo2 extends Foo
{
static function Baz()
{
echo 'Baz';
}
}
Foo2::Bar();
?>
In this case I expect to find 'Baz' on my screen, but I get the
following: "Fatal error: Call to undefined method Foo::baz() in
d:\htdocs_php5\ProBase2\TRUNK\probase\libsys\test5.php on line 7".
This is in PHP5 RC2.
Somehow this behaviour seems logical, on the other hand I don't think
it's desired. I think that 'self' should point to the current class,
even if the static method resides in a parent class.
Is this 'self'-behaviour intended?
Bert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Use of 'self' in static function in subclass
Hi, > Somehow this behaviour seems logical, on the other hand I don't think > it's desired. I think that 'self' should point to the current class, > even if the static method resides in a parent class. > > Is this 'self'-behaviour intended? Furthermore this renders the template-method pattern quite useless, so IMHO it should be changed. Stephan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Use of 'self' in static function in subclass
Bert Slagter wrote:
Hi All,
I have a class and a subclass, both with a static method:
class Foo2 extends Foo
{
static function Baz()
{
echo 'Baz';
}
}
Foo2::Bar();
?>
In this case I expect to find 'Baz' on my screen, but I get the
following: "Fatal error: Call to undefined method Foo::baz() in
d:\htdocs_php5\ProBase2\TRUNK\probase\libsys\test5.php on line 7".
This is in PHP5 RC2.
Somehow this behaviour seems logical, on the other hand I don't think
it's desired. I think that 'self' should point to the current class,
even if the static method resides in a parent class.
Yeah, this probably should change to be consistent. I've been living
fine with the current behavior, but considering self::*() will
automatically invoke the parent class' method if none is defined in
current class, then it should probably also work the other way around.
My .02,
Hans
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
This is indeed very strange. I made some fixes to the memory manager a few days ago. Have you tried a version since then? Andi At 02:50 PM 6/1/2004 +0200, Wolfgang Drews wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > Anything else that needs to go into RC3? maybe not so important for *nixer, but for Windows: I have a really annoying Memory Leak here on my Dev-Station with WinXP and the latest snaps-built (from tomorrow). Every call of a php- script increases the memory-usage of apache about 3-4 MB, so that in consequence the apache takes up about 700MB memory after some reloads of a php-script. Killing this apache-process is the only way to free memory again. This behavior appears since some earlier CVS-Builts (Don't know the exact one). Sorry, that i have no more details to give, but if you tell me what to do, i would be happy to support you with finding a solution. cheers -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Use of 'self' in static function in subclass
On 1 Jun 2004 at 15:21, Stephan Schmidt wrote: > Furthermore this renders the template-method pattern quite useless, so > IMHO it should be changed. He should define an abstract method Foo::Baz() here. -- Ferdinand Beyer <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem in Order of PHP Shutdown
There is a problem in the order the destructors of objects are destroyed at PHP shutdown. Let's say in an destructor the objects tries to save some states in a session variable that would currently fail since destructors are called after modules are freed. Sample & patch included. ./regards Florian Schaper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
*This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > This is indeed very strange. I made some fixes to the memory > manager a few > days ago. Have you tried a version since then? before writing to this list, i've download the latest CVS-Snap Win-Built from snaps.php.net. Problem still existed, so i decided to tell you (Build Date Jun 1 2004 12:13:54). cheers -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
Ferdinand Beyer wrote:
On 1 Jun 2004 at 15:21, Stephan Schmidt wrote:
Furthermore this renders the template-method pattern quite
useless, so
IMHO it should be changed.
He should define an abstract method Foo::Baz() here.
Yes, I agree that design-wise that would be better -- but it will still
fail w/ E_FATAL in PHP if the method is abstract ("cannot call abstract
method Foo::Baz() in ").
Hans
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
Ferdinand Beyer wrote: He should define an abstract method Foo::Baz() here. This is a minimal testcase, in my real life situation there indeed is a 'abstract static function Baz();' in Class Foo. But indeed, then a "Fatal error: Cannot call abstract method Foo::Baz() in.." arises.. Bert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
On 1 Jun 2004 at 16:19, Bert Slagter wrote: > This is a minimal testcase, in my real life situation there indeed is a > 'abstract static function Baz();' in Class Foo. But indeed, then a > "Fatal error: Cannot call abstract method Foo::Baz() in.." arises.. OK, this is indeed a problem then. -- Ferdinand Beyer <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] delete in PHP
An Zend API 2.0 paper I read a while ago said something about "delete" being implemented in PHP5. However, no delete. Was this feature dropped? I have implemented delete for myself now and was wondering if it was worth committing. ./regards Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
On Tue, 1 Jun 2004, Florian Schaper wrote: > An Zend API 2.0 paper I read a while ago said something about "delete" being > implemented in PHP5. > However, no delete. > > Was this feature dropped? I have implemented delete for myself now and was > wondering if it was worth committing. unset($obj) works just fine too. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #28597
[EMAIL PROTECTED] wrote: > Please send the patch to [EMAIL PROTECTED] referring to this > bugreport (and a simple analysis describing why the current code is > wrong). Referring to bug http://bugs.php.net/bug.php?id=28597, I have made the attached patch. The piece of code modified translates a char to a numeric entity, but it not translate correctly codes where (code % 100 < 10). Thanks, Nemec -- []s Fernando Nemec [EMAIL PROTECTED] http://www.folha.com.br/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
Derick Rethans wrote: > On Tue, 1 Jun 2004, Florian Schaper wrote: > >> An Zend API 2.0 paper I read a while ago said something about >> "delete" being implemented in PHP5. >> However, no delete. >> >> Was this feature dropped? I have implemented delete for myself now >> and was wondering if it was worth committing. > > unset($obj) works just fine too. > My version of delete works like the delete we know from C++. The object's destructor and the object is then released immediately. All references of this object are set to IS_NULL. Some might argue that this is a feature not worth having if you have an garbage collector but I can think about a few uses. ./regards Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC3
Wolfgang Drews wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, This is indeed very strange. I made some fixes to the memory manager a few days ago. Have you tried a version since then? before writing to this list, i've download the latest CVS-Snap Win-Built from snaps.php.net. Problem still existed, so i decided to tell you (Build Date Jun 1 2004 12:13:54). can we drop this "ts memory manager," its been causing leaks for quite a while and, from my understanding, only speeds up the threaded case. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
> andi Tue Jun 1 07:45:46 2004 EDT
>
> Modified files:
> /ZendEngine2 zend.c
> Log:
> - If user error handler returns "false" then we relay to the built in error
> handler
>
>
> http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284&r2=1.285&ty=u
> Index: ZendEngine2/zend.c
> diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285
> --- ZendEngine2/zend.c:1.284 Fri May 28 13:28:33 2004
> +++ ZendEngine2/zend.cTue Jun 1 07:45:46 2004
> @@ -17,7 +17,7 @@
> +--+
> */
>
> -/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */
> +/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */
>
> #include "zend.h"
> #include "zend_extensions.h"
> @@ -974,7 +974,7 @@
>
> if (call_user_function_ex(CG(function_table), NULL,
> orig_user_error_handler, &retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) {
> if (retval) {
> - if (Z_TYPE_P(retval) != IS_NULL &&
> !zend_is_true(retval)) {
> + if (Z_TYPE_P(retval) == IS_BOOL &&
> Z_LVAL_P(retval) == 0) {
> zend_error_cb(type, error_filename,
> error_lineno, format, args);
> }
> zval_ptr_dtor(&retval);
>
> --
> Zend Engine CVS Mailing List (http://cvs.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
On 1 Jun 2004 at 16:50, Florian Schaper wrote: > My version of delete works like the delete we know from C++. The object's > destructor and the object is then released immediately. All references of > this object are set to IS_NULL. > > Some might argue that this is a feature not worth having if you have an > garbage collector but I can think about a few uses. There has been a heated discussion on this topic and the conclusion was to drop delete. Please search the archives for pros and cons. -- Ferdinand Beyer <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I think it's OK to add.
At 09:26 AM 6/1/2004 -0700, Andrei Zmievski wrote:
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
> andi Tue Jun 1 07:45:46 2004 EDT
>
> Modified files:
> /ZendEngine2 zend.c
> Log:
> - If user error handler returns "false" then we relay to the built in
error
> handler
>
>
> http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284&r2=1.285&ty=u
> Index: ZendEngine2/zend.c
> diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285
> --- ZendEngine2/zend.c:1.284 Fri May 28 13:28:33 2004
> +++ ZendEngine2/zend.cTue Jun 1 07:45:46 2004
> @@ -17,7 +17,7 @@
>
+--+
> */
>
> -/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */
> +/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */
>
> #include "zend.h"
> #include "zend_extensions.h"
> @@ -974,7 +974,7 @@
>
> if (call_user_function_ex(CG(function_table),
NULL, orig_user_error_handler, &retval, 5, params, 1, NULL
TSRMLS_CC)==SUCCESS) {
> if (retval) {
> - if (Z_TYPE_P(retval) != IS_NULL
&& !zend_is_true(retval)) {
> + if (Z_TYPE_P(retval) == IS_BOOL
&& Z_LVAL_P(retval) == 0) {
> zend_error_cb(type,
error_filename, error_lineno, format, args);
> }
> zval_ptr_dtor(&retval);
>
> --
> Zend Engine CVS Mailing List (http://cvs.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC3
On Windows the ZEND_MM isn't being used (we use Windows specific memory pools), so it's really not relevant. With my tests ZEND_MM is faster than malloc() even on non-threaded servers. In any case, the important thing right now is to try and track down the Windows problem which is not related. I'm not quite sure when it was introduced. My latest fixes weren't supposed to touch that code. In any case, if ZEND_MM ends up causing problems I don't mind leaving it out but right now I prefer leaving it in because of its advantages. Andi At 09:26 AM 6/1/2004 -0700, Sterling Hughes wrote: Wolfgang Drews wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, This is indeed very strange. I made some fixes to the memory manager a few days ago. Have you tried a version since then? before writing to this list, i've download the latest CVS-Snap Win-Built from snaps.php.net. Problem still existed, so i decided to tell you (Build Date Jun 1 2004 12:13:54). can we drop this "ts memory manager," its been causing leaks for quite a while and, from my understanding, only speeds up the threaded case. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I'd like to see this in PHP4 too.
-Rasmus
On Tue, 1 Jun 2004, Andrei Zmievski wrote:
> Should we add this to PHP 4 as well?
>
> On Tue, 01 Jun 2004, Andi Gutmans wrote:
> > andiTue Jun 1 07:45:46 2004 EDT
> >
> > Modified files:
> > /ZendEngine2zend.c
> > Log:
> > - If user error handler returns "false" then we relay to the built in error
> > handler
> >
> >
> > http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284&r2=1.285&ty=u
> > Index: ZendEngine2/zend.c
> > diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285
> > --- ZendEngine2/zend.c:1.284Fri May 28 13:28:33 2004
> > +++ ZendEngine2/zend.c Tue Jun 1 07:45:46 2004
> > @@ -17,7 +17,7 @@
> > +--+
> > */
> >
> > -/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */
> > +/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */
> >
> > #include "zend.h"
> > #include "zend_extensions.h"
> > @@ -974,7 +974,7 @@
> >
> > if (call_user_function_ex(CG(function_table), NULL,
> > orig_user_error_handler, &retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) {
> > if (retval) {
> > - if (Z_TYPE_P(retval) != IS_NULL &&
> > !zend_is_true(retval)) {
> > + if (Z_TYPE_P(retval) == IS_BOOL &&
> > Z_LVAL_P(retval) == 0) {
> > zend_error_cb(type, error_filename,
> > error_lineno, format, args);
> > }
> > zval_ptr_dtor(&retval);
> >
> > --
> > Zend Engine CVS Mailing List (http://cvs.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> - Andrei
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
*This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > In any case, the important thing right now is to try and > track down the > Windows problem which is not related. I'm not quite sure when it was > introduced. My latest fixes weren't supposed to touch that code. were you able to reproduce the memleak? Or need any more infos? I just looked up my php5-download-dir and for sure the leak was there with this built: May 21 2004 20:14:07 let me know, if i can help cheers -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
I made some changes about 4 days ago. Can you try a build from the past day or two? Andi At 06:59 PM 6/1/2004 +0200, Wolfgang Drews wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > In any case, the important thing right now is to try and > track down the > Windows problem which is not related. I'm not quite sure when it was > introduced. My latest fixes weren't supposed to touch that code. were you able to reproduce the memleak? Or need any more infos? I just looked up my php5-download-dir and for sure the leak was there with this built: May 21 2004 20:14:07 let me know, if i can help cheers -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
*This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > I made some changes about 4 days ago. Can you try a build > from the past day > or two? sorry, i have no snapshot from this date. As i said before, my last snapshot is from 21.05.2004 and there the problem existed already. so the bug must have been intoduced earlier i guess. -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
Can you get a June 1 snapshot from http://snaps.php.net/ and let me know? Thanks, Andi At 07:07 PM 6/1/2004 +0200, Wolfgang Drews wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, > I made some changes about 4 days ago. Can you try a build > from the past day > or two? sorry, i have no snapshot from this date. As i said before, my last snapshot is from 21.05.2004 and there the problem existed already. so the bug must have been intoduced earlier i guess. -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] abuse-proof zif_mail()
> when it comes to mail(), it is a whole different story. if i disabled mail() > on just one box today, a *lot* of people would complain and with good > reason - the collateral inflicted by something that drastic (ie disabling a > very popular function to protect against a relative edge case) is way out of > line. i am not an anti-spam fanatic, the clients' requirements come first. > The whole matter is moot because no matter how aggressively you block access to mail(), sendmail, et. al. The user can still make socket calls directly using SMTP commands. The protocol is not hard to understand and it's the neerdowells that you're talking about stopping not the innocent accidentals. -Sara "Locks are to keep the honest people honest." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] abuse-proof zif_mail()
sara, - Original Message - From: "Sara Golemon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 01, 2004 1:06 PM Subject: Re: [PHP-DEV] [patch] abuse-proof zif_mail() --- snip --- > The whole matter is moot because no matter how aggressively you block access > to mail(), sendmail, et. al. The user can still make socket calls directly > using SMTP commands. The protocol is not hard to understand and it's the > neerdowells that you're talking about stopping not the innocent accidentals. i disagree. first off, at least on our setup, users can *try* to make socket calls directly but it won't get them too far - we have iptables ACLs preventing that. second off, the direct socket connections take more time than calling sendmail and dumping it all in our spool and the abuser would have to keep reloading the page (i know this can be automated) because of the 30 second exec time limit. additionally, you could say that i care less about them spewing directly than i care about them dumping twenty thousand messages into our spool, when the relative effects on other clients' service are considered. third off, this patch does not *stop* them per se, it just helps us identify who is responsible so we can act on the abuse reports fast enough not to get baclklisted by some maniac. i am not arguing for making this the default, but quite honestly i do not see a substantive reason not to make this a compile-time or a run-time option. if there is a problem with the *how* of it, i will be glad to correct the patch. i am also willing to produce a patch that will make it an option, whether a compile or a run time one, if people tell me it is going to be included. since we will always want this turned on, there is no point in me mucking about with that if the patch is not going to be accepted. cheers, paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RC3
*This message was transferred with a trial version of CommuniGate(tm) Pro* > Can you get a June 1 snapshot from http://snaps.php.net/ and > let me know? > Thanks, np. but as i said before, i've got the latest already, BEFORE i startet this discussion :). Nevertheless i once more took the VERY latest (php5-win32-200406011430) but memleak is still there. cheers -Wolfgang -- PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de/ Professionelle Lösungen für dynamisches Webpublishing: http://php-buch.de/ Thanks Wolfgang: http://www.amazon.de/exec/obidos/wishlist/C1MRGJEWB3SB/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug#27555 / Problem in Order of PHP Shutdown v. II
A friend of mine had the same Problem as stated in "bug"-Report 27555 and I "fixed" it before checking back with the bug-Database ... Why not to call the destructors before the modules are shut down? I wrote a short patch for this and it works out fine. That does not mean however that it does not break something vital that skipped my attention. http://www.intux.org/download/patches/patch_php_cvs_01_06_04.rar ../Regards Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Overloaded property access
I've just made use of overloaded property access for the first time and
experienced some unexpected behavior. I just wanted to verify that it was
the correct behavior with those who'd know best.
two = new Two();
}
public function __set( $n, $v ) {
$GLOBALS[$n] = $v;
}
public function __get( $n ) {
return $GLOBALS[$n];
}
}
class Two {
public $property = "default value";
}
$one = new One();
print( "\"" . $one->two->property . "\"n" );
$one->two->property = "new value";
?>
This produces:
=
$ php -f test.php
"default value"
PHP Fatal error: Cannot access undefined property for object with
overloaded property access in /home/fletch/test.php on line 24
=
Is it correct that $one->two->property should be read only?
Thanks.
Rick Fletcher
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
On Tue, 2004-06-01 at 15:11, Bert Slagter wrote:
> Hi All,
>
> I have a class and a subclass, both with a static method:
[...]
> Somehow this behaviour seems logical, on the other hand I don't think
> it's desired. I think that 'self' should point to the current class,
> even if the static method resides in a parent class.
>
> Is this 'self'-behaviour intended?
Yes: self is bound at compiletime. It would need to be changed to
evaluation at runtime und would be far more useful then.
This has been reported a couple of times, in slight variations:
http://zend.com/lists/engine2/200307/msg00033.html
http://zend.com/lists/engine2/200307/msg00036.html
http://zend.com/lists/engine2/200309/msg00024.html
In one of these, Marcus suggested a new keyword "this" which would
behave like a run-time self, e.g:
class Test {
public static function getInstance() {
return new this();
}
}
class Foo extends Test {
}
var_dump(Foo::getInstance());
would output "object(foo)" instead of "object(test)". I wouldn't mind
chaning self in the first place, though.
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
On 1 Jun 2004 at 21:13, Timm Friebe wrote: > Yes: self is bound at compiletime. It would need to be changed to > evaluation at runtime und would be far more useful then. > > [...] > > I wouldn't mind chaning self in the first place, though. I prefer your solution to evaluate self at runtime instead of adding a new keyword 'this'. The second one would only be confused with $this. Many people (including me) are already familiar with 'self' and expect it to refer to the class from within it is called. -- Ferdinand Beyer <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
On Tue, 2004-06-01 at 16:50, Florian Schaper wrote:
> Derick Rethans wrote:
> > On Tue, 1 Jun 2004, Florian Schaper wrote:
> >
> >> An Zend API 2.0 paper I read a while ago said something about
> >> "delete" being implemented in PHP5.
> >> However, no delete.
> >>
> >> Was this feature dropped? I have implemented delete for myself now
> >> and was wondering if it was worth committing.
> >
> > unset($obj) works just fine too.
> >
>
> My version of delete works like the delete we know from C++. The object's
> destructor and the object is then released immediately. All references of
> this object are set to IS_NULL.
In comparison to the proposed "delete", unset() only decreases the
refcount.
Have a look at the following examples:
$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); unset($o); echo "Shutting down\n";'
Destroyed
Shutting down
$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); $o2= $o; unset($o); echo "Shutting down\n";'
Shutting down
Destroyed
In the second example, the destructor is not called until *after*
shutdown. This is the small but noticeable difference between what
Florian wants and what we currently provide.
While I agree this could be interesting, I'm opposed to a keyword named
"delete". Keywords may not be used as regular method names and a new
keyword "delete" would add more BC breaks for people using methods
called delete(). This:
class DBConnection {
function insert() { }
function update() { }
function select() { }
function delete() { }
}
is an example which can be seen in numerous applications.
Then again, why doesn't unset() do this? That seems kind of inconsistent
with the object-handle-pass-by-value semantics we have in PHP5.
For the time being, using reference operators and setting the instance
to NULL gives you a workaround:
$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); $o2= &$o; $o= NULL; echo "Shutting down\n";'
Destroyed
Shutting down
Interesting enough (from a user's pov, not the Engine's), unset() will
not do the job:
$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); $o2= &$o; unset($o); echo "Shutting down\n";'
Shutting down
Destroyed
(neither will omitting the & in the first solution).
- Ti "back to references after all?" mm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Overloaded property access
After sending this mail I went and searched the bugs database more
thoroughly and found this very problem here:
http://bugs.php.net/bug.php?id=28444.
My apologies.
Rick
> -Original Message-
> From: Rick Fletcher [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 01, 2004 11:41a
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Overloaded property access
>
> I've just made use of overloaded property access for the
> first time and
> experienced some unexpected behavior. I just wanted to
> verify that it was
> the correct behavior with those who'd know best.
>
>
> class One {
> public function __construct() {
> $this->two = new Two();
> }
>
> public function __set( $n, $v ) {
> $GLOBALS[$n] = $v;
> }
>
> public function __get( $n ) {
> return $GLOBALS[$n];
> }
> }
>
> class Two {
> public $property = "default value";
> }
>
> $one = new One();
>
> print( "\"" . $one->two->property . "\"n" );
>
> $one->two->property = "new value";
>
> ?>
>
> This produces:
> =
> $ php -f test.php
> "default value"
> PHP Fatal error: Cannot access undefined property for object with
> overloaded property access in /home/fletch/test.php on line 24
> =
>
> Is it correct that $one->two->property should be read only?
>
> Thanks.
>
> Rick Fletcher
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
Timm Friebe wrote:
[...]
> In comparison to the proposed "delete", unset() only decreases the
> refcount.
>
> Have a look at the following examples:
>
> $ php-dev -r 'class Object { function __destruct() { echo
> "Destroyed\n"; }} $o= new Object(); unset($o); echo "Shutting
> down\n";'
> Destroyed
> Shutting down
>
> $ php-dev -r 'class Object { function __destruct() { echo
> "Destroyed\n"; }} $o= new Object(); $o2= $o; unset($o); echo
> "Shutting down\n";' Shutting down
> Destroyed
>
> In the second example, the destructor is not called until *after*
> shutdown. This is the small but noticeable difference between what
> Florian wants and what we currently provide.
>
> While I agree this could be interesting, I'm opposed to a keyword
> named "delete". Keywords may not be used as regular method names and
> a new keyword "delete" would add more BC breaks for people using
> methods called delete(). This:
>
> class DBConnection {
> function insert() { }
> function update() { }
> function select() { }
> function delete() { }
> }
>
> is an example which can be seen in numerous applications.
>
I really dont't want to warm up an discussion that has already been dealt
with,
but from my pov. - while I agree one should keep them to a minimum - minor
changes are
to be excpected in a major jump in version numbers and I'm sure this is not
unprecedented. Then again I don't get the eMails from the developers
going on about their broken code and I wouldn't want to volunteer for that.
For completeness:
Proposed behaviour of delete as opposed to unset:
$ php-dev -r 'class Object { function __destruct() { echo
"Destroyed\n"; }} $o= new Object(); $o2= &$o; delete $o; var_export( $o );
var_export( $o2 ); echo
"Shutting down\n";' Destroyed NULL NULL Shutting down
> Then again, why doesn't unset() do this? That seems kind of
> inconsistent with the object-handle-pass-by-value semantics we have
> in PHP5.
>
> For the time being, using reference operators and setting the instance
> to NULL gives you a workaround:
>
> $ php-dev -r 'class Object { function __destruct() { echo
> "Destroyed\n"; }} $o= new Object(); $o2= &$o; $o= NULL; echo
> "Shutting down\n";' Destroyed
> Shutting down
>
> Interesting enough (from a user's pov, not the Engine's), unset() will
> not do the job:
>
> $ php-dev -r 'class Object { function __destruct() { echo
> "Destroyed\n"; }} $o= new Object(); $o2= &$o; unset($o); echo
> "Shutting down\n";' Shutting down
> Destroyed
I for one could manage without a delete keyword with unset destroying
the object referenced - which looks for me a more consistent
behaviour as Timm pointed out.
./regards
Florian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
Ferdinand Beyer wrote: On 1 Jun 2004 at 21:13, Timm Friebe wrote: Yes: self is bound at compiletime. It would need to be changed to evaluation at runtime und would be far more useful then. [...] I wouldn't mind chaning self in the first place, though. I prefer your solution to evaluate self at runtime instead of adding a new keyword 'this'. The second one would only be confused with $this. Many people (including me) are already familiar with 'self' and expect it to refer to the class from within it is called. Yeah +1 on self:: binding at runtime. I can't really imagine a case where you would want to refer to 'self' as the class that contains the method *and not* the overridden method in invoked class (if it exists). Binding this at runtime will introduce many new design possibilities with static classes and will also make self:: consistent with $this-> behavior for objects. Hans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
On Tue, 2004-06-01 at 19:53, Hans Lellelid wrote: > Yeah +1 on self:: binding at runtime. I can't really imagine a case > where you would want to refer to 'self' as the class that contains the > method *and not* the overridden method in invoked class (if it exists). > Binding this at runtime will introduce many new design possibilities > with static classes and will also make self:: consistent with $this-> > behavior for objects. +1, I agree completely. I think it is critical to have a way to be able to have a static method call another static method in the same class that respects inheritance. If a developer wanted a call to not respect inheritance the class's name can be used instead of self with the same results (increased code maintenance should the class name change notwithstanding). -- Adam Bregenzer [EMAIL PROTECTED] http://adam.bregenzer.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
It's something I noticed, too. Consider this:
class A {
function a() { return $this::b(); }
function b() { return 1; }
}
class B extends A {
function b() { return 2; }
}
If I call
$b = new B();
echo $b->a();
No matter what combination of this, self, parent, ... - I could never get
B's property. I was led to believe that this is actually normal for OO
designs (is it? If so, ignore me). But it would be awesome if self or $this
(ONLY one of them, if they currently perform the same function) actually
referred to the top class - ie. B::b() in this case. Is this what this
suggestion would suggest?
Thanks,
Jevon
- Original Message -
From: "Adam Bregenzer" <[EMAIL PROTECTED]>
To: "Hans Lellelid" <[EMAIL PROTECTED]>
Cc: "Ferdinand Beyer" <[EMAIL PROTECTED]>; "Timm Friebe" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, June 02, 2004 12:26 PM
Subject: Re: [PHP-DEV] Use of 'self' in static function in subclass
> On Tue, 2004-06-01 at 19:53, Hans Lellelid wrote:
> > Yeah +1 on self:: binding at runtime. I can't really imagine a case
> > where you would want to refer to 'self' as the class that contains the
> > method *and not* the overridden method in invoked class (if it exists).
> > Binding this at runtime will introduce many new design possibilities
> > with static classes and will also make self:: consistent with $this->
> > behavior for objects.
>
> +1, I agree completely. I think it is critical to have a way to be able
> to have a static method call another static method in the same class
> that respects inheritance. If a developer wanted a call to not respect
> inheritance the class's name can be used instead of self with the same
> results (increased code maintenance should the class name change
> notwithstanding).
>
> --
> Adam Bregenzer
> [EMAIL PROTECTED]
> http://adam.bregenzer.net/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
On Tue, 2004-06-01 at 19:45, Florian Schaper wrote:
> For completeness:
> Proposed behaviour of delete as opposed to unset:
> $ php-dev -r 'class Object { function __destruct() { echo
> "Destroyed\n"; }} $o= new Object(); $o2= &$o; delete $o; var_export( $o );
> var_export( $o2 ); echo
> "Shutting down\n";' Destroyed NULL NULL Shutting down
I could see this being useful, it certainly would make destructors much
more useful. However, I think it is also unnecessary in a language like
PHP. Additionally, since you can not be certain of the order
destructors are called in for objects when a script is terminated
(unless I missed a fix for this) it may cause an unhealthy dependence on
destructors. This could end with people having to put a bunch of delete
calls at the end of their functions/scripts/etc. to guarantee everything
wraps up sanely. I think this would be a very bad thing, not only
because it harbors memories of C/C++ but also because it would be
another confusing thing to teach new php OO coders.
> > Then again, why doesn't unset() do this? That seems kind of
> > inconsistent with the object-handle-pass-by-value semantics we have
> > in PHP5.
[snip]
> I for one could manage without a delete keyword with unset destroying
> the object referenced - which looks for me a more consistent
> behaviour as Timm pointed out.
The operation of unset makes sense to me and should, imho, not change.
It is used when you want to clear a particular variable of its contents,
not necessarily destroy the data; afaik it is similar to (if this were
valid):
$var =& null;
Looking at the examples and description in the manual[1] seems to
confirm this behavior in functions as well. As a result, if you wanted
to use unset to delete an object you would have to unset every variable
that contains a reference to it, as it should be for unset.
In my PHP OO coding so far I have come across many instances where I
need unset's type of functionality. One example of is in "poking holes"
in an array (ex. unset($arr['key']);). If unset also went through and
destroyed every copy of that instance it would seem to me to be a very
unexpected and bad result. Also, I can't work around it by setting the
array entry to null because the key would still exist. If a method
similar to delete is needed I vote for it having its own name. Possibly
inst_delete to reduce naming conflicts?
As a side note I have used count as a method name in a class before
without error. I assume that since it is a method of a class it does
not conflict with the existing count[2] function, even though it may,
arguably, be bad coding style.
[1] http://www.php.net/unset
[2] http://www.php.net/count
--
Adam Bregenzer
[EMAIL PROTECTED]
http://adam.bregenzer.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] delete in PHP
On Tue, 1 Jun 2004, Ferdinand Beyer wrote: > On 1 Jun 2004 at 16:50, Florian Schaper wrote: > > > My version of delete works like the delete we know from C++. The > > object's destructor and the object is then released immediately. All > > references of this object are set to IS_NULL. > > > > Some might argue that this is a feature not worth having if you have > > an garbage collector but I can think about a few uses. > > There has been a heated discussion on this topic and the conclusion > was to drop delete. Please search the archives for pros and cons. Right, let's stop this thread here. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
