[PHP-DEV] RFE 34986: Adding an object field to debug_backtrace()
For some Meta Programming tool for PHP that I am working on it would be nice to have an additional object field in the array returned by debug_backtrace() that contains a reference to the respective object on the callstack. After some looking into the zend_fetch_debug_backtrace() function I wrote a patch that I attached to my RFE [1]. It would be great if someone with a more intimate knowledge of the Zend Engine's internals could look at my patch and give me some feedback. (Even greater would be the acception of this patch :-) Thanks, Sebastian -- [1] http://bugs.php.net/bug.php?id=34986 -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Questions about static and serialization
Hi internals, I was experimenting with different approaches of maintaining state and serializing objects in PHP5. The problem is handling static class members and static variables inside methods. First, I noted that static variables inside methods are shared between instances. C++ seems to handle it the same way, but admittedly, I was a little bit surprised: Such variables are available as local variables in methods that are called using an instance, i. e. non-statically, whereas static class variables can only be accessed using a static reference to a class (self::, parent:: or Classname::). However, this explains why static variables inside functions do not show up when serializing object instances: Because the static variable is - just like a static class variable - not part of the object, but belongs to the class. So - has anybody ever considered serializing static variables as well? Obviously they have to be treated separately at a per-class level; let alone static variables in functions outside classes ;). Would it be possible to write a session serialize handler that somehow includes such static elements? I presume it should be possible to somewhere find the static elements. (Strictly spoken, an object instance's state expresses itself in non-static members of the instance, so the above static variables in functions stuff makes sense the way it is - if I want to maintain per-instance state, I shouldn't be using local static variables, but plain object members for that. However, when working with the Singleton pattern, you don't come around using static at some level...) Best regards, Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions about static and serialization
As you mentioned, static properties and statically scoped variables don't belong to an object instance, so it doesn't make sense to serialize them. --Wez. On 10/26/05, Matthias Pigulla [EMAIL PROTECTED] wrote: Hi internals, I was experimenting with different approaches of maintaining state and serializing objects in PHP5. The problem is handling static class members and static variables inside methods. First, I noted that static variables inside methods are shared between instances. C++ seems to handle it the same way, but admittedly, I was a little bit surprised: Such variables are available as local variables in methods that are called using an instance, i. e. non-statically, whereas static class variables can only be accessed using a static reference to a class (self::, parent:: or Classname::). However, this explains why static variables inside functions do not show up when serializing object instances: Because the static variable is - just like a static class variable - not part of the object, but belongs to the class. So - has anybody ever considered serializing static variables as well? Obviously they have to be treated separately at a per-class level; let alone static variables in functions outside classes ;). Would it be possible to write a session serialize handler that somehow includes such static elements? I presume it should be possible to somewhere find the static elements. (Strictly spoken, an object instance's state expresses itself in non-static members of the instance, so the above static variables in functions stuff makes sense the way it is - if I want to maintain per-instance state, I shouldn't be using local static variables, but plain object members for that. However, when working with the Singleton pattern, you don't come around using static at some level...) Best regards, Matthias -- 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
[PHP-DEV] CVS Account Request: mikl
Work on the memcache pecl extension, I spoke with Antony Dovgal about this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: foreach with null
Any opinions? Good code is code that's easy to debug (among other things). By removing the Invalid argument supplied for foreach() warning without providing mechanisms to turn it on, debugging code will be more difficult. Logically speaking, when does it make sense to iterate over something that isn't an array? If I were writing one-time use scripts that I will never use again (not likely) this might be desired behavior. If I were writing code that is used by other programmers, paying users, and under conditions likely to change (implying changing code, and often debugging and testing), the ability to detect errors as early as possible is vital (The Pragmatic Programmer is a good reference for this). Most people don't want to spend more time than is necessary to troubleshoot code. Probably more importantly, managers and customers don't want to wait longer for a product they're paying for. Understandly, PHP aims to be easy in so many ways, but I believe in order for PHP to survive in the enterprise and allow users to easily write good code, it *must* support such features. Without features like these, writing PHP won't be so easy because the work required to do the checking is forced on the programmer. The Invalid argument supplied for foreach() warning should not be removed unless it can be done without breaking compatibility and with a way to optionally turn it on/off. I think we can learn a good lesson from Perl on this one. Here is how we turn on/off warnings, lexically: use warnings; - sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO: Are there plans to support Mysql 5 soon?
Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. Best regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach with null
Sebastian wrote: Good code is code that's easy to debug (among other things). By removing the Invalid argument supplied for foreach() warning without providing mechanisms to turn it on, debugging code will be more difficult. Logically speaking, when does it make sense to iterate over something that isn't an array? If I were writing one-time use scripts that I will never use again (not likely) this might be desired behavior. If I were writing code that is used by other programmers, paying users, and under conditions likely to change (implying changing code, and often debugging and testing), the ability to detect errors as early as possible is vital (The Pragmatic Programmer is a good reference for this). Most people don't want to spend more time than is necessary to troubleshoot code. Probably more importantly, managers and customers don't want to wait longer for a product they're paying for. I also don't feel very comfortable with silencing the warning for NULL. If the variable is not an array and not traversable there's nothing to iterate over and it should tell the user. If we intentionally want to not know about this error, an alternate syntax with the '@' operator should be considered as it was requested in the past, e.g. '@foreach' or 'foreach(@$notarrayOrIterable ...'. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO: Are there plans to support Mysql 5 soon?
On 26.10.2005 21:22, Holografix wrote: Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. What's the problem with MySQL 5 ? Did you try ext/mysqli ( http://php.net/mysqli ) ? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO: Are there plans to support Mysql 5 soon?
On Wed, 2005-10-26 at 18:22 +0100, Holografix wrote: With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. I use PDO with MySQL 5 every day. What's the problem? -- Jasper Bryant-Greene General Manager Album Limited e: [EMAIL PROTECTED] w: http://www.album.co.nz/ p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303 a: PO Box 579, Christchurch 8015, New Zealand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO: Are there plans to support Mysql 5 soon?
Hi I know mysqli but already have some code (dao classes) based on pdo and I would like to keep it. Thanks anyway. Best regards holo Antony Dovgal [EMAIL PROTECTED] escreveu na mensagem news:[EMAIL PROTECTED] On 26.10.2005 21:22, Holografix wrote: Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. What's the problem with MySQL 5 ? Did you try ext/mysqli ( http://php.net/mysqli ) ? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO: Are there plans to support Mysql 5 soon?
Hi I know mysqli but already have some code (dao classes) based on pdo and I would like to keep it. I am almost sure I read a message from Wez Furlong saying that pdo doesn't actualy support mysql 5 sometime ago. I will try it in a couple of hours. Now it's time to dinner and watch a football game. Thank you very much. Best regards holo Antony Dovgal [EMAIL PROTECTED] escreveu na mensagem news:[EMAIL PROTECTED] On 26.10.2005 21:22, Holografix wrote: Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. What's the problem with MySQL 5 ? Did you try ext/mysqli ( http://php.net/mysqli ) ? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO: Are there plans to support Mysql 5 soon?
Hi I know mysqli but already have some code (dao classes) based on pdo and I would like to keep it. I am almost sure I read a message from Wez Furlong saying that pdo doesn't actualy support mysql 5 sometime ago. I will try it in a couple of hours. Now it's time to dinner and watch a football game. Thank you very much. Best regards holo Antony Dovgal [EMAIL PROTECTED] escreveu na mensagem news:[EMAIL PROTECTED] On 26.10.2005 21:22, Holografix wrote: Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. What's the problem with MySQL 5 ? Did you try ext/mysqli ( http://php.net/mysqli ) ? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespace methods
Hello, I have been trying to compile PHP with the namespaces patch, but have been completely unable to find the time after an initial attempt failed (I'm compiling on windows). So I just wanted to know what methods this patch provides, if it does at all. Does it support import for example? If so, is there any documentation on the methods the patch provides? Thanks, Kevin N. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Are there plans to support Mysql 5 soon?
Hi I am almost sure I read a message from Wez Furlong saying that pdo doesn't actualy support mysql 5 sometime ago. I will try it in a couple of hours. Now it's time to dinner and watch a football game. Thank you very much. Best regards holo Holografix [EMAIL PROTECTED] escreveu na mensagem news:[EMAIL PROTECTED] Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. Best regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
What I said was something along the lines of me not going to knock myself out with a beta version of mysql when we're trying to push out a release. Unless the client API seriously changed in mysql 5, there should be no reason that PHP will stop working if you upgrade to mysql 5. --Wez. On 10/26/05, Holografix [EMAIL PROTECTED] wrote: Hi I am almost sure I read a message from Wez Furlong saying that pdo doesn't actualy support mysql 5 sometime ago. I will try it in a couple of hours. Now it's time to dinner and watch a football game. Thank you very much. Best regards holo Holografix [EMAIL PROTECTED] escreveu na mensagem news:[EMAIL PROTECTED] Hi With PHP 5.1 knocking at the door, I guess many people would like to take advantage og mysql 5 new features. Best regards -- 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
[PHP-DEV] Re: Namespace methods
Kevin, Just to make sure, you can get the latest patch from http://www.zend.com/zend/week/pat/pat44.txt. For documentation, please refer to this post: http://news.php.net/php.internals/17484. Let me know if you have any questions or if you still cannot get the patch to compile (I wrote the patch against a 5.1 CVS version some months ago, maybe it doesn't apply cleanly anymore, haven't tried). Regards, Jessie Hernandez Kevin Newman wrote: Hello, I have been trying to compile PHP with the namespaces patch, but have been completely unable to find the time after an initial attempt failed (I'm compiling on windows). So I just wanted to know what methods this patch provides, if it does at all. Does it support import for example? If so, is there any documentation on the methods the patch provides? Thanks, Kevin N. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach with null
On Wed, 26 Oct 2005, Sebastian wrote: [clip] Good code is code that's easy to debug (among other things). By removing the Invalid argument supplied for foreach() warning without providing mechanisms to turn it on, debugging code will be more difficult. [clip] You got to the point here. I'd like to see E_STRICT be used for this if this NULL thing is accepted. Also, I found out recently something that I didn't know about before and which I count as inconsistent: count(somethingthatisnotanemptyarraynorobjectnornull) returns int(1). It would be nice that count() would also produce an E_STRICT notice when passed something else than object or array. Or rather make every single function and language construct to produce the E_STRICT notice when passed wrong type of variable. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach with null
Jani Taskinen wrote:
On Wed, 26 Oct 2005, Sebastian wrote:
[clip]
Good code is code that's easy to debug (among other things). By
removing the Invalid argument supplied for foreach() warning without
providing mechanisms to turn it on, debugging code will be more
difficult.
[clip]
You got to the point here. I'd like to see E_STRICT be used for this
if this NULL thing is accepted. Also, I found out recently something
that I didn't know about before and which I count as inconsistent:
count(somethingthatisnotanemptyarraynorobjectnornull) returns int(1).
It would be nice that count() would also produce an E_STRICT notice
when passed something else than object or array. Or rather make
every single function and language construct to produce the E_STRICT
notice when passed wrong type of variable.
amen, this behavior makes no sense even though sizeof() is an alias to
count(). sizeof('this') and sizeof('this long thing') are both 1, which
makes no sense. I would go so far as to say a E_NOTICE is more
appropriate than E_STRICT - you should only be using count() for
arrays/objects.
Then Zend could remove the silly question from the cert example exam ;).
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Questions about static and serialization
Von: Wez Furlong [mailto:[EMAIL PROTECTED] As you mentioned, static properties and statically scoped variables don't belong to an object instance, so it doesn't make sense to serialize them. Ok, but on the other hand they are just variables - so the question was if there is any (possibly userland) way to capture them in the line with normal session handling, by using (un)serialize or whatever. As to persisting and restoring structures like the singleton pattern, I just noticed that the builtin serialization/persistence mechanisms don't care about object identity at all... :( Best regards, Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach with null
Greg Beaver wrote:
amen, this behavior makes no sense even though sizeof() is an alias to
count(). sizeof('this') and sizeof('this long thing') are both 1, which
makes no sense. I would go so far as to say a E_NOTICE is more
appropriate than E_STRICT - you should only be using count() for
arrays/objects.
Actually this result makes perfect sense since type conversion changes
string into array('your string') and does a count of that, which is 1.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
pdo_mysql is not version specific, it'll work with 3.23,4.0,4.1 and even 5.0 version of MySQL. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
Ilia Alshanetsky schrieb: pdo_mysql is not version specific, it'll work with 3.23,4.0,4.1 and even 5.0 version of MySQL. Well, now it is not anymore. I had to wait several months not being able to use PDO because my Windows/XAMPP was already using MySQL 4.1 and the PDO betas were _not_ functioning. So, those careful complaints about will it work? are very much valid ;-) OLLi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
On 27.10.2005 01:58, Oliver Grätz wrote: Ilia Alshanetsky schrieb: pdo_mysql is not version specific, it'll work with 3.23,4.0,4.1 and even 5.0 version of MySQL. Well, now it is not anymore. I had to wait several months not being able to use PDO because my Windows/XAMPP was already using MySQL 4.1 and the PDO betas were _not_ functioning. So, those careful complaints about will it work? are very much valid ;-) # mysql -V mysql Ver 14.12 Distrib 5.0.13-rc, for pc-linux-gnu (i686) using readline 5.0 All ext/pdo_mysql tests are doing fine here, as well as ext/mysql ext/mysqlI ones. Personally I do not see a reason to call it not functioning or something like that. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
Do you read the posts you're commenting on? I said there _were_ (there are not anymore) problems with PDO betas on _Windows_ systems (that was a PECL build for PHP 5.0.3). This was not a complaint on anything and I didn't complain then because it was beta and not meant to be used with PHP 5.0.x, it's just to support that it is reasonable for people to ask will it work?. The fact is that XAMPP/Win32 users could not start using PDO from PECL for several months without having to downgrade their MySQL and that was known (I read something in german about all the nasty changes in MySQL happenend in 4.1 but -- Murphy's Law -- I can't find the source, from some PHP conference, anymore using Google). OLLi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach with null
Ilia Alshanetsky wrote:
IMHO this is a bad idea, if you really wanted to support NULL in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'
Making NULL usage transparent where array is expects will lead to
difficult to debug code.
hi :-)
the warning for foreach() in this case seems to be inconsistent with:
php -r '$a = null; $b = array(); var_dump((empty($a) === empty($b)), (count($a)
=== count($b)));'
which gives no warnings or otherwise, also as a lesser developer than you I
don't
buy the notion that dropping the warning makes debugging more difficult because
advanced code should be checking vars properly before using them and, well,
for any given foreach loop there is often enough an 'if (!count($array))'-like
statement to take care of the 'empty' case. and in cases when speed is very
important
it saves an explicit cast (is that more expensive anyway?) and it means not
requiring
an '@' to suppress which I do know is more expensive than not having any E_* to
suppress at all.
on the face of it I understand begin against, feedback is good.
but removing the warning would make the engine behaviour just a little
more consistent - which is nice, no?
sidenote
did anyone remember that php5beta used to allow:
function(MyCLass $x = null) {}
which was nice from the start fom a user perspective,
I was puzzled as to why it went, glad it came back and
hope it says :-)
/sidenote
thanks for php, and kind regards in general,
jochem
-1 for removing the warning.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach with null
Ilia Alshanetsky wrote:
Greg Beaver wrote:
amen, this behavior makes no sense even though sizeof() is an alias to
count(). sizeof('this') and sizeof('this long thing') are both 1, which
makes no sense. I would go so far as to say a E_NOTICE is more
appropriate than E_STRICT - you should only be using count() for
arrays/objects.
Actually this result makes perfect sense since type conversion changes
string into array('your string') and does a count of that, which is 1.
Yes, it makes sense from this perspective, but from a real-life
programming perspective it is
1) useless - count() provides no useful information about strings
2) potentially buggy.
For instance, PEAR's XML_Unserializer (XML_Serializer package)
represents XML elements with simple text node children as a string, and
tags with anything else (attributes, child elements) as an array.
Improperly written code that uses count() without checking is_array()
would happily run with no warning whatsoever. However, imho it would
make PHP more robust if the logical error condition were also a language
error, that's all.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are there plans to support Mysql 5 soon?
Oliver Grätz wrote: Do you read the posts you're commenting on? I said there _were_ (there are not anymore) problems with PDO betas on _Windows_ systems (that was a PECL build for PHP 5.0.3). This was not a complaint on anything and I didn't complain then because it was beta and not meant to be used with PHP 5.0.x, it's just to support that it is reasonable for people to ask will it work?. I remember when FreeBSD didn't support ELF binaries. Does that mean that it's reasonable for me to ping the FreeBSD dev list with 'when will you support ELF?' without checking whether or not that support works? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
