Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
Fair enough Wez :) On Thu, 2005-08-25 at 20:34 -0400, Wez Furlong wrote: In some environments you *need* to run a zts enabled PHP. People that run in those environments can heed the warnings about potential stability issues, evaluate them, and decide whether it makes sense for their application. I don't see any compelling need to rip out a feature that is essential for some platforms, just because it might not work so well on others. --Wez. On 8/25/05, John Coggeshall [EMAIL PROTECTED] wrote: On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote: There are almost no advantages to multithreaded PHP. There are disadvantages (the reduced stability is inherent; no matter how good PHP gets, multi-process deployments are by definition more robust). Performance is slightly degraded too, so why bother? I'm not saying we should get rid of the thread safe mode, but frankly, the main reason is that it doesn't bother anybody and is useful for some people. Not because I think we'll ever quite get there. Why not just get rid of it then? (i.e. something as simple as just not allowing it to be turned on at all) and instead provide a nice automated fastCGI install in its place? I seem to recall seeing something somewhere along the line about fastCGI being faster then prefork Apache as well (there was a patch?), if I am remembering correctly wouldn't it make sense to make that the default installation method across the board? At the very least it makes sense for threaded environments obviously... John -- 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] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
At 03:34 26/08/2005, Wez Furlong wrote: In some environments you *need* to run a zts enabled PHP. People that run in those environments can heed the warnings about potential stability issues, evaluate them, and decide whether it makes sense for their application. I don't see any compelling need to rip out a feature that is essential for some platforms, just because it might not work so well on others. It's a good thing I read through the thread before replying :) That's exactly why I think we shouldn't get rid of it. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Thu, 25 Aug 2005, Ilia Alshanetsky wrote: I think there is a good reason for this patch making its way into PHP 5.1 and 5.0, any chance relevant RMs could be convinced to allow it? :-) Patch for 5.1 is here: http://files.derickrethans.nl/patches/e_recoverable_error-php-5.1-20050826.diff.txt Feel free to apply it while I'm on a short holiday. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Wed, 24 Aug 2005, Zeev Suraski wrote: At 09:26 24/08/2005, Derick Rethans wrote: On Tue, 23 Aug 2005, Andi Gutmans wrote: I didn't quite understand. Users would be able to handle E_FATAL errors? How would exceptions from those user handlers propagate the C extensions? No, they would only be able to catch E_ERROR, E_FATAL is the current E_ERROR and can NOT be caught by the user defined error handler. New status (or atleast, IMO): E_NOTICE: Just for little notices to inform the user that something might have gone wrong. E_WARNING: Something went wrong, probably resulting in unwanted behavior. No change here (good!) E_ERROR: An error situation occurred, which is probably dangerous for a script to continue, but does not leave the Engine itself in an unstable state. If this one is not caught in a user defined error handler, the application aborts. E_FATAL: The engine is in an unstable state, we have to abort. Not catchable by a user defined error handler. Replacing the meaning of E_ERROR is elegant, but it does create a problem of cross-version compatibility of extensions (at the source code level). If you want to raise an error that terminates execution, you'll have to do it in two different ways - that's quite annoying. While I think there are a lot of situations where E_ERROR is an overkill, there are tons of situations where it isn't, so this is an issue. Given that, I think we should go with the introduction of a new error level, E_RECOVERABLE_ERROR, and keep E_ERROR with its existing meaning. I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt Any comments? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
At 10:17 25/08/2005, Marcus Boerger wrote: Hello Andi, wow, now that makes me wonder if you perhaps also know a reason for? I mean in theory it should be faster shouldn't it? Or is the problem that we far to often use TRSMLS_FETCH() with all its disadvantages? Whenever we touch a shared resource (primarily in TSRMLS_FETCH()), it's a slight slowdown. Passing on the context everywhere is also a slight slowdown, but it's probably slight enough to be barely noticeable. The bottom line is that it is a bit slower, and much more prone to bugs. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote: I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt Any comments? +1 overall. As much as I like to keep name short, I think the full E_RECOVERABLE_ERROR maybe better in this case, just be 100% clear it is an error constant. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Thu, 25 Aug 2005, Zeev Suraski wrote: At 15:44 25/08/2005, Ilia Alshanetsky wrote: Derick Rethans wrote: I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt Any comments? +1 overall. As much as I like to keep name short, I think the full E_RECOVERABLE_ERROR maybe better in this case, just be 100% clear it is an error constant. Same here. Fine I'll update that then - I don't really care :) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Thu, 25 Aug 2005, Derick Rethans wrote: On Thu, 25 Aug 2005, Zeev Suraski wrote: At 15:44 25/08/2005, Ilia Alshanetsky wrote: Derick Rethans wrote: I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt Any comments? +1 overall. As much as I like to keep name short, I think the full E_RECOVERABLE_ERROR maybe better in this case, just be 100% clear it is an error constant. Same here. Fine I'll update that then - I don't really care :) Updated patch: http://files.derickrethans.nl/patches/e_recoverable_error-20050825.diff.txt If there is nothing else, I'd like to commit it soonish. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Ilia Alshanetsky wrote: I think there is a good reason for this patch making its way into PHP 5.1 and 5.0, any chance relevant RMs could be convinced to allow it? :-) Not sure about 5.0, but it should go into (yet unreleased) 5.1 IMHO. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello Zeev, Thursday, August 25, 2005, 2:55:43 PM, you wrote: At 15:44 25/08/2005, Ilia Alshanetsky wrote: Derick Rethans wrote: I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt Any comments? +1 overall. As much as I like to keep name short, I think the full E_RECOVERABLE_ERROR maybe better in this case, just be 100% clear it is an error constant. Same here. here too and i know some of our users would pretty much appreciate this. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
I don't buy into the argument that we shouldn't start even trying to solve the thread safety issues in PHP because of some arbitrary we can't tell or it's faster not to do it sort of argument. Threads aren't exactly an archaic or edge technology, and it's just stubborn of us not to support them. Having a means by which to identify and keep track of what extensions are considered thread safe is the only way to take a reasonable step forward on this issue. Saying TS of an ext could change with every commit is a bogus argument (anything can), and although it's reasonable to say there is a slight speed loss to PHP itself when operating in threaded mode we are simply supporting the technology not recommending it. On Thu, 2005-08-25 at 09:17 +0200, Marcus Boerger wrote: Hello Andi, wow, now that makes me wonder if you perhaps also know a reason for? I mean in theory it should be faster shouldn't it? Or is the problem that we far to often use TRSMLS_FETCH() with all its disadvantages? best regards marcus Thursday, August 25, 2005, 1:28:49 AM, you wrote: Marcus, You will most likely find that the faster Apache way with thread-safe PHP is slower than the slower Apache way with non-thread-safe PHP. And even FastCGI will be faster :) Andi At 12:25 PM 8/24/2005, Marcus Boerger wrote: Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote: On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
I generally disagree. There are almost no advantages to multithreaded PHP. There are disadvantages (the reduced stability is inherent; no matter how good PHP gets, multi-process deployments are by definition more robust). Performance is slightly degraded too, so why bother? And yes, unlike most things, thread safety is difficult to obtain and very difficult to retain. So the 'every commit' statement is not bogus at all. It's easier to screw thread safety than just about anything else :) I wrote TSRM and made most of PHP thread safe, and I can tell you it was a bitch to stabilize, and 4.5 years later the job is still not completely done. When Shane started pushing towards FastCGI I initially resented the idea, but after a while he convinced me. I fail to find any disadvantages to FastCGI, and it comes with the great advantage of cross-process isolation. I'm not saying we should get rid of the thread safe mode, but frankly, the main reason is that it doesn't bother anybody and is useful for some people. Not because I think we'll ever quite get there. Zeev At 22:35 25/08/2005, John Coggeshall wrote: I don't buy into the argument that we shouldn't start even trying to solve the thread safety issues in PHP because of some arbitrary we can't tell or it's faster not to do it sort of argument. Threads aren't exactly an archaic or edge technology, and it's just stubborn of us not to support them. Having a means by which to identify and keep track of what extensions are considered thread safe is the only way to take a reasonable step forward on this issue. Saying TS of an ext could change with every commit is a bogus argument (anything can), and although it's reasonable to say there is a slight speed loss to PHP itself when operating in threaded mode we are simply supporting the technology not recommending it. On Thu, 2005-08-25 at 09:17 +0200, Marcus Boerger wrote: Hello Andi, wow, now that makes me wonder if you perhaps also know a reason for? I mean in theory it should be faster shouldn't it? Or is the problem that we far to often use TRSMLS_FETCH() with all its disadvantages? best regards marcus Thursday, August 25, 2005, 1:28:49 AM, you wrote: Marcus, You will most likely find that the faster Apache way with thread-safe PHP is slower than the slower Apache way with non-thread-safe PHP. And even FastCGI will be faster :) Andi At 12:25 PM 8/24/2005, Marcus Boerger wrote: Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote: On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
I don't think anyone was arguing that we should fix TS issues. We've been doing that for ages (since the early days of PHP 4). The question is wether there is much value in marking extensions as thread-safe. At 12:35 PM 8/25/2005, John Coggeshall wrote: I don't buy into the argument that we shouldn't start even trying to solve the thread safety issues in PHP because of some arbitrary we can't tell or it's faster not to do it sort of argument. Threads aren't exactly an archaic or edge technology, and it's just stubborn of us not to support them. Having a means by which to identify and keep track of what extensions are considered thread safe is the only way to take a reasonable step forward on this issue. Saying TS of an ext could change with every commit is a bogus argument (anything can), and although it's reasonable to say there is a slight speed loss to PHP itself when operating in threaded mode we are simply supporting the technology not recommending it. On Thu, 2005-08-25 at 09:17 +0200, Marcus Boerger wrote: Hello Andi, wow, now that makes me wonder if you perhaps also know a reason for? I mean in theory it should be faster shouldn't it? Or is the problem that we far to often use TRSMLS_FETCH() with all its disadvantages? best regards marcus Thursday, August 25, 2005, 1:28:49 AM, you wrote: Marcus, You will most likely find that the faster Apache way with thread-safe PHP is slower than the slower Apache way with non-thread-safe PHP. And even FastCGI will be faster :) Andi At 12:25 PM 8/24/2005, Marcus Boerger wrote: Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote: On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote: There are almost no advantages to multithreaded PHP. There are disadvantages (the reduced stability is inherent; no matter how good PHP gets, multi-process deployments are by definition more robust). Performance is slightly degraded too, so why bother? ... I'm not saying we should get rid of the thread safe mode, but frankly, the main reason is that it doesn't bother anybody and is useful for some people. Not because I think we'll ever quite get there. Why not just get rid of it then? (i.e. something as simple as just not allowing it to be turned on at all) and instead provide a nice automated fastCGI install in its place? I seem to recall seeing something somewhere along the line about fastCGI being faster then prefork Apache as well (there was a patch?), if I am remembering correctly wouldn't it make sense to make that the default installation method across the board? At the very least it makes sense for threaded environments obviously... John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
As Zeev stated it's additional thread-storage fetching and passing an extra parameter. However, it's a marginal difference so I wouldn't base my architectural decision on that. It was only regarding performance decision. I wouldn't base my architecture decision solely based on performance but also stability and ease-of-deployment and management. Andi At 12:17 AM 8/25/2005, Marcus Boerger wrote: Hello Andi, wow, now that makes me wonder if you perhaps also know a reason for? I mean in theory it should be faster shouldn't it? Or is the problem that we far to often use TRSMLS_FETCH() with all its disadvantages? best regards marcus Thursday, August 25, 2005, 1:28:49 AM, you wrote: Marcus, You will most likely find that the faster Apache way with thread-safe PHP is slower than the slower Apache way with non-thread-safe PHP. And even FastCGI will be faster :) Andi At 12:25 PM 8/24/2005, Marcus Boerger wrote: Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote: On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
In some environments you *need* to run a zts enabled PHP. People that run in those environments can heed the warnings about potential stability issues, evaluate them, and decide whether it makes sense for their application. I don't see any compelling need to rip out a feature that is essential for some platforms, just because it might not work so well on others. --Wez. On 8/25/05, John Coggeshall [EMAIL PROTECTED] wrote: On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote: There are almost no advantages to multithreaded PHP. There are disadvantages (the reduced stability is inherent; no matter how good PHP gets, multi-process deployments are by definition more robust). Performance is slightly degraded too, so why bother? I'm not saying we should get rid of the thread safe mode, but frankly, the main reason is that it doesn't bother anybody and is useful for some people. Not because I think we'll ever quite get there. Why not just get rid of it then? (i.e. something as simple as just not allowing it to be turned on at all) and instead provide a nice automated fastCGI install in its place? I seem to recall seeing something somewhere along the line about fastCGI being faster then prefork Apache as well (there was a patch?), if I am remembering correctly wouldn't it make sense to make that the default installation method across the board? At the very least it makes sense for threaded environments obviously... John -- 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] type hinting throwing a fatal error
On Tue, 23 Aug 2005, Andi Gutmans wrote: I didn't quite understand. Users would be able to handle E_FATAL errors? How would exceptions from those user handlers propagate the C extensions? No, they would only be able to catch E_ERROR, E_FATAL is the current E_ERROR and can NOT be caught by the user defined error handler. New status (or atleast, IMO): E_NOTICE: Just for little notices to inform the user that something might have gone wrong. E_WARNING: Something went wrong, probably resulting in unwanted behavior. E_ERROR: An error situation occurred, which is probably dangerous for a script to continue, but does not leave the Engine itself in an unstable state. If this one is not caught in a user defined error handler, the application aborts. E_FATAL: The engine is in an unstable state, we have to abort. Not catchable by a user defined error handler. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 09:26 24/08/2005, Derick Rethans wrote: On Tue, 23 Aug 2005, Andi Gutmans wrote: I didn't quite understand. Users would be able to handle E_FATAL errors? How would exceptions from those user handlers propagate the C extensions? No, they would only be able to catch E_ERROR, E_FATAL is the current E_ERROR and can NOT be caught by the user defined error handler. New status (or atleast, IMO): E_NOTICE: Just for little notices to inform the user that something might have gone wrong. E_WARNING: Something went wrong, probably resulting in unwanted behavior. No change here (good!) E_ERROR: An error situation occurred, which is probably dangerous for a script to continue, but does not leave the Engine itself in an unstable state. If this one is not caught in a user defined error handler, the application aborts. E_FATAL: The engine is in an unstable state, we have to abort. Not catchable by a user defined error handler. Replacing the meaning of E_ERROR is elegant, but it does create a problem of cross-version compatibility of extensions (at the source code level). If you want to raise an error that terminates execution, you'll have to do it in two different ways - that's quite annoying. While I think there are a lot of situations where E_ERROR is an overkill, there are tons of situations where it isn't, so this is an issue. Given that, I think we should go with the introduction of a new error level, E_RECOVERABLE_ERROR, and keep E_ERROR with its existing meaning. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Wed, 24 Aug 2005, Zeev Suraski wrote: At 09:26 24/08/2005, Derick Rethans wrote: On Tue, 23 Aug 2005, Andi Gutmans wrote: I didn't quite understand. Users would be able to handle E_FATAL errors? How would exceptions from those user handlers propagate the C extensions? No, they would only be able to catch E_ERROR, E_FATAL is the current E_ERROR and can NOT be caught by the user defined error handler. New status (or atleast, IMO): E_NOTICE: Just for little notices to inform the user that something might have gone wrong. E_WARNING: Something went wrong, probably resulting in unwanted behavior. No change here (good!) E_ERROR: An error situation occurred, which is probably dangerous for a script to continue, but does not leave the Engine itself in an unstable state. If this one is not caught in a user defined error handler, the application aborts. E_FATAL: The engine is in an unstable state, we have to abort. Not catchable by a user defined error handler. Replacing the meaning of E_ERROR is elegant, but it does create a problem of cross-version compatibility of extensions (at the source code level). If you want to raise an error that terminates execution, you'll have to do it in two different ways - that's quite annoying. While I think there are a lot of situations where E_ERROR is an overkill, there are tons of situations where it isn't, so this is an issue. As this is only for PHP 6, I dont see a real reason as if those extensions get updated for Unicode, things like returning ERRORs should be revised anyway. (In any case, people *should* go through their extension and check whether they still conform to our error guidelines). Given that, I think we should go with the introduction of a new error level, E_RECOVERABLE_ERROR, and keep E_ERROR with its existing meaning. I can change that, but IMO it's less elegant. What do others think? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Replacing the meaning of E_ERROR is elegant, but it does create a problem of cross-version compatibility of extensions (at the source code level). If you want to raise an error that terminates execution, you'll have to do it in two different ways - that's quite annoying. While I think there are a lot of situations where E_ERROR is an overkill, there are tons of situations where it isn't, so this is an issue. As this is only for PHP 6, I dont see a real reason as if those extensions get updated for Unicode, things like returning ERRORs should be revised anyway. (In any case, people *should* go through their extension and check whether they still conform to our error guidelines). If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? Given that, I think we should go with the introduction of a new error level, E_RECOVERABLE_ERROR, and keep E_ERROR with its existing meaning. I can change that, but IMO it's less elegant. What do others think? If it counts for anything, I'm with Zeev over this one. I think version compatibility's likely to become an issue in unexpected ways, and also the meaning of E_USER_ERROR is less intuitive because it wouldn't behave in a similar way to E_ERROR any more. E_RECOVERABLE_ERROR's too long though - what's wrong with E_RECOVERABLE? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 17:21 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Not that I agree with Derick on changing the meaning of E_ERROR. I think we should strive for maintaining source level compatibility. I don't think it's a good feature to break the compatibility on purpose :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Rasmus, Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Ouf - you're effectively saying that Unicode support will need to be enabled via INI directives on a per-extension basis? Or that there will need to be two versions of every PHP extension? Not that I agree with Derick on changing the meaning of E_ERROR. :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Ouf - you're effectively saying that Unicode support will need to be enabled via INI directives on a per-extension basis? Or that there will need to be two versions of every PHP extension? Not at all. But it would be nice if the extension did something intelligent when passed an IS_UNICODE string. IS_UNICODE strings don't just exist when unicode semantics are turned on either. So it actually doesn't matter if that switch is on or not, extensions should handle Unicode strings. OK, thanks for the clarification. - Steph -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
At 17:37 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: Hi Rasmus, Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Ouf - you're effectively saying that Unicode support will need to be enabled via INI directives on a per-extension basis? Or that there will need to be two versions of every PHP extension? Not at all. But it would be nice if the extension did something intelligent when passed an IS_UNICODE string. IS_UNICODE strings don't just exist when unicode semantics are turned on either. So it actually doesn't matter if that switch is on or not, extensions should handle Unicode strings. Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. ? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
Zeev Suraski wrote: At 17:37 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: Hi Rasmus, Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Ouf - you're effectively saying that Unicode support will need to be enabled via INI directives on a per-extension basis? Or that there will need to be two versions of every PHP extension? Not at all. But it would be nice if the extension did something intelligent when passed an IS_UNICODE string. IS_UNICODE strings don't just exist when unicode semantics are turned on either. So it actually doesn't matter if that switch is on or not, extensions should handle Unicode strings. Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Doesn't this go against what you just said about breaking things on purpose? I don't think we need anything beyond the API versioning here. We should be able to deal with extensions that correctly use zend_parse_parameters for their argument handling. But for extensions that don't, I think there is no way to maintain source compatibility and I think it may be an idea to stop these from even building. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Wed, 24 Aug 2005, Zeev Suraski wrote: At 17:21 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Not that I agree with Derick on changing the meaning of E_ERROR. I think we should strive for maintaining source level compatibility. I don't think it's a good feature to break the compatibility on purpose :) I just implemented a suggestion by somebody (George! :). I don't care which way we go. I'll update the patch to go for E_RECOVERABLE_ERROR tomorrow. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Not that I agree with Derick on changing the meaning of E_ERROR. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
At 17:46 24/08/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: At 17:37 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: Hi Rasmus, Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Ouf - you're effectively saying that Unicode support will need to be enabled via INI directives on a per-extension basis? Or that there will need to be two versions of every PHP extension? Not at all. But it would be nice if the extension did something intelligent when passed an IS_UNICODE string. IS_UNICODE strings don't just exist when unicode semantics are turned on either. So it actually doesn't matter if that switch is on or not, extensions should handle Unicode strings. Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Doesn't this go against what you just said about breaking things on purpose? I don't think we need anything beyond the API versioning here. Not quite; As far as binary compatibility we agree, there's no way we'll retain binary compatibility, and API versioning is the built-in method to notify users about that. But, you mentioned (and I agree) that it would be annoying for things to stop working if unicode is turned on. While it's impossible to truly prevent that from happening (we can't force everybody to maintain unicode-compatible code everywhere), we can give extension authors a way to denote whether their extensions are compatible with unicode or not. If not - these extensions will become inaccessible when unicode semantics is enabled. We should be able to deal with extensions that correctly use zend_parse_parameters for their argument handling. But for extensions that don't, I think there is no way to maintain source compatibility and I think it may be an idea to stop these from even building. Why? A great deal of users will be running with unicode semantics turned off, and I don't see a good reason to break source compatibility for them. For example, if Foo Inc. wrote a module for PHP 4, and they want to migrate to PHP 6 - it should be a simple recompile. It's OK if we barf when they turn unicode_sematics off, but not if they don't. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
Zeev Suraski wrote: Why? A great deal of users will be running with unicode semantics turned off, and I don't see a good reason to break source compatibility for them. For example, if Foo Inc. wrote a module for PHP 4, and they want to migrate to PHP 6 - it should be a simple recompile. It's OK if we barf when they turn unicode_sematics off, but not if they don't. What happens when the extension gets an IS_UNICODE string passed to it if they are not using zend_parse_parameters()? These strings can exist independent of the unicode semantics switch. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
At 18:05 24/08/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: Why? A great deal of users will be running with unicode semantics turned off, and I don't see a good reason to break source compatibility for them. For example, if Foo Inc. wrote a module for PHP 4, and they want to migrate to PHP 6 - it should be a simple recompile. It's OK if we barf when they turn unicode_sematics off, but not if they don't. What happens when the extension gets an IS_UNICODE string passed to it if they are not using zend_parse_parameters()? These strings can exist independent of the unicode semantics switch. Sure, it would work reasonably well because of our typeless nature. Everything gets convert_to_()'d before it's touched. Of course you'd be able to shoot yourself in the foot by explicitly creating unicode strings and using them with non-unicode functions with unicode_semantics turned off, but the wound wouldn't be too bad :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote: On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
Hello Zeev, Wednesday, August 24, 2005, 4:41:25 PM, you wrote: At 17:37 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: Hi Rasmus, Steph wrote: If there's the capability to run PHP 6 without Unicode support, surely there's no reason for extensions to lose back compatability when they're updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are changing which a runtime switch can't do anything about. We may be able to keep compatibility at the source level, but having extensions that fall over when you turn on unicode semantics would be a real pain. It might be a feature to break them and have a nice FAQ on what needs to be done to upgrade the extension to support Unicode. Ouf - you're effectively saying that Unicode support will need to be enabled via INI directives on a per-extension basis? Or that there will need to be two versions of every PHP extension? Not at all. But it would be nice if the extension did something intelligent when passed an IS_UNICODE string. IS_UNICODE strings don't just exist when unicode semantics are turned on either. So it actually doesn't matter if that switch is on or not, extensions should handle Unicode strings. Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. What is this, a try to incorporate a way of creating BC issue on purpose before releasing and without the ability to fix them later? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
At 08:05 AM 8/24/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: Why? A great deal of users will be running with unicode semantics turned off, and I don't see a good reason to break source compatibility for them. For example, if Foo Inc. wrote a module for PHP 4, and they want to migrate to PHP 6 - it should be a simple recompile. It's OK if we barf when they turn unicode_sematics off, but not if they don't. What happens when the extension gets an IS_UNICODE string passed to it if they are not using zend_parse_parameters()? These strings can exist independent of the unicode semantics switch. Well you can't resolve all problems but if they are expecting strings then they will work (unicode strings will be converted to native strings). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
Marcus, You will most likely find that the faster Apache way with thread-safe PHP is slower than the slower Apache way with non-thread-safe PHP. And even FastCGI will be faster :) Andi At 12:25 PM 8/24/2005, Marcus Boerger wrote: Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote: On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote: Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error. Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety? Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much. Best regards, Marcus -- 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] type hinting throwing a fatal error
On Mon, 22 Aug 2005, George Schlossnagle wrote: E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) I have a patch for this ready. In most of the engine I converted all E_ERRORs to E_FATALs (except the type hints), and in most of the extensions I kept the E_ERRORs in case there is proper error handling for cases where an E_ERROR would not have aborted. Major exceptions here are ext/hwapi, ext/soap, ext/simplexml and ext/ming. These need to be fixed. In some cases I added RETURN_FALSE or return. I also updated some test cases. You can find the patch here: http://files.derickrethans.nl/e_fatal-20050823.diff.txt Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Derick, I didn't quite understand. Users would be able to handle E_FATAL errors? How would exceptions from those user handlers propagate the C extensions? Andi At 05:15 AM 8/23/2005, Derick Rethans wrote: On Mon, 22 Aug 2005, George Schlossnagle wrote: E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) I have a patch for this ready. In most of the engine I converted all E_ERRORs to E_FATALs (except the type hints), and in most of the extensions I kept the E_ERRORs in case there is proper error handling for cases where an E_ERROR would not have aborted. Major exceptions here are ext/hwapi, ext/soap, ext/simplexml and ext/ming. These need to be fixed. In some cases I added RETURN_FALSE or return. I also updated some test cases. You can find the patch here: http://files.derickrethans.nl/e_fatal-20050823.diff.txt Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- 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] type hinting throwing a fatal error
Generally speaking, many users want to be able to catch every error possible. If there is an error condition that happens, they want to be able to catch it. If it's not possible to catch it in script, perhaps an extension or some other strategy needs to be documented for certain error conditions. Anyone who develops systems with 99.99 or 99.999% availability (~5 minutes downtime per year) needs to account for all error conditions, and this is required in things like telephone systems, military systems, etc. Hey, you may want a web interface to those systems ;) Regards, Al On Tue, 2005-08-23 at 16:12 -0700, Andi Gutmans wrote: Hi Derick, I didn't quite understand. Users would be able to handle E_FATAL errors? How would exceptions from those user handlers propagate the C extensions? Andi At 05:15 AM 8/23/2005, Derick Rethans wrote: On Mon, 22 Aug 2005, George Schlossnagle wrote: E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) I have a patch for this ready. In most of the engine I converted all E_ERRORs to E_FATALs (except the type hints), and in most of the extensions I kept the E_ERRORs in case there is proper error handling for cases where an E_ERROR would not have aborted. Major exceptions here are ext/hwapi, ext/soap, ext/simplexml and ext/ming. These need to be fixed. In some cases I added RETURN_FALSE or return. I also updated some test cases. You can find the patch here: http://files.derickrethans.nl/e_fatal-20050823.diff.txt Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- 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] type hinting throwing a fatal error
On Thu, 11 Aug 2005, Derick Rethans wrote: On Thu, 11 Aug 2005, Zeev Suraski wrote: You mean it shouldn't be able to stop the application, or that the application should be able to prevent this error from stopping it? If it's the latter, then it would be possible. If it's the former, then I don't quite understand... The latter is fine too. Okay, shall I give it a go as implementation? It seems most are for another type of error that are fatal if not handled in the user error handler. There is just one thing... how do we signal it back from the handler? Currently there is no defined return value for the user defined error handler. I suggest that if you return false from the user defined error handler than that signals that PHP should handle the error (and this stop the application in case the new error type was thrown). Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 12:53 22/08/2005, Derick Rethans wrote: On Thu, 11 Aug 2005, Derick Rethans wrote: On Thu, 11 Aug 2005, Zeev Suraski wrote: You mean it shouldn't be able to stop the application, or that the application should be able to prevent this error from stopping it? If it's the latter, then it would be possible. If it's the former, then I don't quite understand... The latter is fine too. Okay, shall I give it a go as implementation? Yep. It seems most are for another type of error that are fatal if not handled in the user error handler. There is just one thing... how do we signal it back from the handler? Currently there is no defined return value for the user defined error handler. I suggest that if you return false from the user defined error handler than that signals that PHP should handle the error (and this stop the application in case the new error type was thrown). I'm not exactly following. If you want to stop the application, why wouldn't you simply exit()? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 22 Aug 2005, Zeev Suraski wrote: It seems most are for another type of error that are fatal if not handled in the user error handler. There is just one thing... how do we signal it back from the handler? Currently there is no defined return value for the user defined error handler. I suggest that if you return false from the user defined error handler than that signals that PHP should handle the error (and this stop the application in case the new error type was thrown). I'm not exactly following. If you want to stop the application, why wouldn't you simply exit()? I *don't* want to stop it :) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 14:34 22/08/2005, Derick Rethans wrote: On Mon, 22 Aug 2005, Zeev Suraski wrote: It seems most are for another type of error that are fatal if not handled in the user error handler. There is just one thing... how do we signal it back from the handler? Currently there is no defined return value for the user defined error handler. I suggest that if you return false from the user defined error handler than that signals that PHP should handle the error (and this stop the application in case the new error type was thrown). I'm not exactly following. If you want to stop the application, why wouldn't you simply exit()? I *don't* want to stop it :) So in that case, the implementation in zend_error_cb() should simply call the user error handler if it's available, or treat it as if it's E_ERROR if there is no user error handler. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 22 Aug 2005, Andrei Zmievski wrote:
I thought I made that patch a while ago?
zend.c:
if (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);
}
Ah, great. I didn't know this. This doesn't solve the problem of the
catchable fatals though. I've a patch for that ready, just need to do
some testing.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello Zeev, Monday, August 22, 2005, 1:38:54 PM, you wrote: At 14:34 22/08/2005, Derick Rethans wrote: On Mon, 22 Aug 2005, Zeev Suraski wrote: It seems most are for another type of error that are fatal if not handled in the user error handler. There is just one thing... how do we signal it back from the handler? Currently there is no defined return value for the user defined error handler. I suggest that if you return false from the user defined error handler than that signals that PHP should handle the error (and this stop the application in case the new error type was thrown). I'm not exactly following. If you want to stop the application, why wouldn't you simply exit()? I *don't* want to stop it :) So in that case, the implementation in zend_error_cb() should simply call the user error handler if it's available, or treat it as if it's E_ERROR if there is no user error handler. Isn't an E_ERROR by default good enough or do you want exceptions here always? In the former case it might be better to have a new error level E_HINT. In the latter case maybe it might be a good idea to move the default exceptions from ext/spl to the engine and have a 'Hint' whatever exception class derived from RunTimeException. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 20:53 22/08/2005, Marcus Boerger wrote: So in that case, the implementation in zend_error_cb() should simply call the user error handler if it's available, or treat it as if it's E_ERROR if there is no user error handler. Isn't an E_ERROR by default good enough or do you want exceptions here always? I'm not sure what happened, but I don't want exceptions at all, let alone always :) In the former case it might be better to have a new error level E_HINT. In the latter case maybe it might be a good idea to move the default exceptions from ext/spl to the engine and have a 'Hint' whatever exception class derived from RunTimeException. One of us is missing something, or we're not talking about the same thing at all. I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/PHP are in a stable state. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Aug 22, 2005, at 3:50 PM, Zeev Suraski wrote: At 20:53 22/08/2005, Marcus Boerger wrote: So in that case, the implementation in zend_error_cb() should simply call the user error handler if it's available, or treat it as if it's E_ERROR if there is no user error handler. Isn't an E_ERROR by default good enough or do you want exceptions here always? I'm not sure what happened, but I don't want exceptions at all, let alone always :) In the former case it might be better to have a new error level E_HINT. In the latter case maybe it might be a good idea to move the default exceptions from ext/spl to the engine and have a 'Hint' whatever exception class derived from RunTimeException. One of us is missing something, or we're not talking about the same thing at all. I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/ PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 22 Aug 2005, George Schlossnagle wrote: I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. Right, my current patch allows you do to that for the new E_CATCHABLE error. I don't like the name though, so we need to come up with a better one (sorry Zeev :) . Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 22:54 22/08/2005, George Schlossnagle wrote: This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. Exactly. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Aug 22, 2005, at 4:02 PM, Derick Rethans wrote: On Mon, 22 Aug 2005, George Schlossnagle wrote: I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. Right, my current patch allows you do to that for the new E_CATCHABLE error. I don't like the name though, so we need to come up with a better one (sorry Zeev :) . My original proposal (at least as I recall it), was to move irrecoverable errors to something like E_UNRECOVERABLE_ERROR or E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
E_CATCHY catchy enough or you? -Andrei On Aug 22, 2005, at 1:02 PM, Derick Rethans wrote: On Mon, 22 Aug 2005, George Schlossnagle wrote: I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. Right, my current patch allows you do to that for the new E_CATCHABLE error. I don't like the name though, so we need to come up with a better one (sorry Zeev :) . Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- 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] type hinting throwing a fatal error
At 23:10 22/08/2005, George Schlossnagle wrote: My original proposal (at least as I recall it), was to move irrecoverable errors to something like E_UNRECOVERABLE_ERROR or E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) I like this idea except it would be a bit of a headache compatibility wise (maybe more than a bit)... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello Zeev, Monday, August 22, 2005, 11:26:12 PM, you wrote: At 23:10 22/08/2005, George Schlossnagle wrote: My original proposal (at least as I recall it), was to move irrecoverable errors to something like E_UNRECOVERABLE_ERROR or E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) I like this idea except it would be a bit of a headache compatibility wise (maybe more than a bit)... Same here, though it shouldn't be a BC issue if you had behaved while coding, since yyou shouldn't depend in anyway on something you're not supposed to be catch anyway or that results in a corruption whatsoever else. And Zeev we werent't on different topics. I was just asking. Asking how complex we were going to make this. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello George, Monday, August 22, 2005, 10:10:24 PM, you wrote: On Aug 22, 2005, at 4:02 PM, Derick Rethans wrote: On Mon, 22 Aug 2005, George Schlossnagle wrote: I'm talking about allowing type hints to be trappable by users, without complicating them with exceptions. I'm proposing a new error level, which behaves like E_ERROR, except it can be caught using a userland error handler, for those cases where the engine/PHP are in a stable state. This sounds good to me. We talked about this briefly a year or so ago, in reference to being able to convert E_ERROR errors to exceptions in an extension. Right, my current patch allows you do to that for the new E_CATCHABLE error. I don't like the name though, so we need to come up with a better one (sorry Zeev :) . My original proposal (at least as I recall it), was to move irrecoverable errors to something like E_UNRECOVERABLE_ERROR or E_FATAL Leaving current errors as E_ERROR (since most are recoverable, imho) Exact same here. And i asked for that before, too (w/o answer iirc). Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 02:28 11/08/2005, Tobias Schlitt wrote: Hi Zeev Suraski! On 08/10/05 17:30 you wrote: I think that throwing exceptions in all sorts of places encourages people to write 'exception-oriented' apps, which is very messy. Sorry, but I consider that statement wrong. We are still talking about PHP and a not caught exception will result into a fatal error. Therefore you do not force anyone to actually write 'exception-oriented' apps. Did I say 'force'? I said 'encourage'. The text of an uncaught exception mentions, well, an uncaught exception. What the heck does that mean? What is an exception and why did it run away? It would encourage people to start learning what exceptions are, a non trivial concept at the least, and one of the first things they'll see is that they can trap them with try/catch. I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). What actually would be the same as having a try block around your application. Right, which is infinitely better. It does not encourage (-- not force) you to write code that recovers from exceptions, but rather - a trap-all just-in-case-something-goes-really-wrong error message. That is a good idea (which we should be doing either way). I definitly agree here, but it does not make sense for type hinting. But heaving the type hints throwing an exception is a really nice feature for large applications, where you are often not sure, which parts of the application will call a function or even worse you're not sure with which objects you act (because of utilizing multiple different libraries, written be even more different people). Having an exception thrown in that case enables you to run surrounded, independant modules to finish their work gracefully instead of shutting down the whole request gracefully. The actual implementation of type hints does not allow them to be used in this case, because having a coding error in just 1 module will screw up all other modules, where just 1 is broken. Well, like I said - sorry, but I consider that statement wrong :) I definitely think that this type of error is the one that is caught during development, and not during runtime, and is fixed as soon as it's found. Writing advanced 'let's try to call this, and if it fails do that' is exactly the kind of stuff I'm trying to avoid. If you really want to do that - you can use the ultra advanced approach and use reflection. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Wed, 10 Aug 2005, Zeev Suraski wrote: Calling to a function with the wrong arguments is something that should be dealt with when developing the application, not at runtime. I think that throwing exceptions in all sorts of places encourages people to write 'exception-oriented' apps, which is very messy. Type hinting is also not exactly an OO thing, it's an object thing, and there's a difference. PHP is filling up with a lot of builtin classes, as well as infrastructure classes, that actually simplify the lives of users, without them having to have a clue about object orientation. Some examples that come to mind are SimpleXML, the SOAP classes and PDO. On a long enough timescale - everybody using PHP will be using objects, and many (if not most) of them will be using them in procedural apps. I see a big negative point in forcibly introducing these people to the concept of exceptions. I agree a 100% here. I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). That is a good idea (which we should be doing either way). That would work well. I just want the type hints to be catchable. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Thu, 11 Aug 2005, Derick Rethans wrote: I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). That is a good idea (which we should be doing either way). That would work well. I just want the type hints to be catchable. Except that it shouldn't be able to stop the application. The reason for this is that Unit Testing on this stuff should still work, and you can't always anticipate what your users do with your libraries. If a user does something wrong in a third party module to your application, and pass a wrong opbject to one of your utility classes, when we do not want the whole application to stop immediately, as it might be just a sub-part of you application which is very possible to ignore for the full working of your application. This is why I first suggested an exception, so that the application can continue. Although in *my* opinion the application just should blow up, other people disagree with me here. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 11:03 11/08/2005, Derick Rethans wrote: On Thu, 11 Aug 2005, Derick Rethans wrote: I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). That is a good idea (which we should be doing either way). That would work well. I just want the type hints to be catchable. Except that it shouldn't be able to stop the application. The reason for this is that Unit Testing on this stuff should still work, and you can't always anticipate what your users do with your libraries. If a user does something wrong in a third party module to your application, and pass a wrong opbject to one of your utility classes, when we do not want the whole application to stop immediately, as it might be just a sub-part of you application which is very possible to ignore for the full working of your application. This is why I first suggested an exception, so that the application can continue. Although in *my* opinion the application just should blow up, other people disagree with me here. You mean it shouldn't be able to stop the application, or that the application should be able to prevent this error from stopping it? If it's the latter, then it would be possible. If it's the former, then I don't quite understand... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Thu, 11 Aug 2005, Zeev Suraski wrote: You mean it shouldn't be able to stop the application, or that the application should be able to prevent this error from stopping it? If it's the latter, then it would be possible. If it's the former, then I don't quite understand... The latter is fine too. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote: On Thu, 11 Aug 2005, Derick Rethans wrote: I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). That is a good idea (which we should be doing either way). That would work well. I just want the type hints to be catchable. Except that it shouldn't be able to stop the application. The reason for this is that Unit Testing on this stuff should still work, and you can't Well UnitTests should always be run in a separate process, so that you can infact to proper edge (or even over the edge) testing. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Thu, 11 Aug 2005, Lukas Smith wrote: Derick Rethans wrote: On Thu, 11 Aug 2005, Derick Rethans wrote: I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). That is a good idea (which we should be doing either way). That would work well. I just want the type hints to be catchable. Except that it shouldn't be able to stop the application. The reason for this is that Unit Testing on this stuff should still work, and you can't Well UnitTests should always be run in a separate process, so that you can infact to proper edge (or even over the edge) testing. I agree, but none of the Unit Test frameworks (except php-tests) do this. I don't think I should be rewriting yet another one. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Zeev Suraski wrote:
I believe we mentioned once the possibility of adding another error
level, which is fatal - but still catchable by set_error_handler().
What actually would be the same as having a try block around your
application.
Right, which is infinitely better. It does not encourage (-- not
force) you to write code that recovers from exceptions, but rather - a
trap-all just-in-case-something-goes-really-wrong error message.
Catch-alls are bad but... There is an even worse case: People start
abusing exceptions for flow control/ normal operation like replacing
something like if ($obj) foo($obj) with try { foo($obj); } catch
(Exception $e) {} because the error message mentions exceptions and/or
because they just learned about it and think it's cool.
If you guys decide to go forward and use an exception for type hinting
(which is a tad more powerful, agreed) then at least make the exception
message very clear that the caller of the function should make sure he
passes the proper object type to the function, NOT that if should be
wrapped in try/catch.
My $.02,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
I don't think that's a good idea, regardless of implementation issues.
Calling to a function with the wrong arguments is something that should be
dealt with when developing the application, not at runtime. I think that
throwing exceptions in all sorts of places encourages people to write
'exception-oriented' apps, which is very messy. Type hinting is also not
exactly an OO thing, it's an object thing, and there's a difference. PHP
is filling up with a lot of builtin classes, as well as infrastructure
classes, that actually simplify the lives of users, without them having to
have a clue about object orientation. Some examples that come to mind are
SimpleXML, the SOAP classes and PDO. On a long enough timescale -
everybody using PHP will be using objects, and many (if not most) of them
will be using them in procedural apps. I see a big negative point in
forcibly introducing these people to the concept of exceptions.
I believe we mentioned once the possibility of adding another error level,
which is fatal - but still catchable by set_error_handler(). That is a
good idea (which we should be doing either way).
Zeev
At 12:50 08/08/2005, Derick Rethans wrote:
Hei,
currently if you pass a wrong object's type to a typehinted parameter:
[EMAIL PROTECTED]:~$ cat /tmp/foo.php
?php
class foo {
function bar(foo $a)
{
}
}
$a = new foo;
$a-bar(new stdClass);
?
[EMAIL PROTECTED]:~$ php /tmp/foo.php
Fatal error: Argument 1 must be an instance of foo in
/tmp/foo.php on
line 3
As type hinting is a new OO thing, it might perhaps make some sense to
make this an exception instead - as this error might also happen for
dynamic things by people who use the classes you designed. In that case
having this fatal error to stop the whole application can be annoying.
Opinions?
Derick
--
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] type hinting throwing a fatal error
Hi Zeev Suraski! On 08/10/05 17:30 you wrote: I think that throwing exceptions in all sorts of places encourages people to write 'exception-oriented' apps, which is very messy. Sorry, but I consider that statement wrong. We are still talking about PHP and a not caught exception will result into a fatal error. Therefore you do not force anyone to actually write 'exception-oriented' apps. I believe we mentioned once the possibility of adding another error level, which is fatal - but still catchable by set_error_handler(). What actually would be the same as having a try block around your application. That is a good idea (which we should be doing either way). I definitly agree here, but it does not make sense for type hinting. But heaving the type hints throwing an exception is a really nice feature for large applications, where you are often not sure, which parts of the application will call a function or even worse you're not sure with which objects you act (because of utilizing multiple different libraries, written be even more different people). Having an exception thrown in that case enables you to run surrounded, independant modules to finish their work gracefully instead of shutting down the whole request gracefully. The actual implementation of type hints does not allow them to be used in this case, because having a coding error in just 1 module will screw up all other modules, where just 1 is broken. Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say thank you?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans schrieb: I prefer not to comment on that :) I might have something to do with that, but I am not sure. -- 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
Re: [PHP-DEV] type hinting throwing a fatal error
On Tue, 9 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: I prefer not to comment on that :) I might have something to do with that, but I am not sure. You've nothing to do with that. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans schrieb: Opinions? +1 -- 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
RE: [PHP-DEV] type hinting throwing a fatal error
+1
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Monday, August 08, 2005 11:50 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] type hinting throwing a fatal error
Hei,
currently if you pass a wrong object's type to a typehinted parameter:
[EMAIL PROTECTED]:~$ cat /tmp/foo.php
?php
class foo {
function bar(foo $a)
{
}
}
$a = new foo;
$a-bar(new stdClass);
?
[EMAIL PROTECTED]:~$ php /tmp/foo.php
Fatal error: Argument 1 must be an instance of foo in /tmp/foo.php
on
line 3
As type hinting is a new OO thing, it might perhaps make some sense to
make this an exception instead - as this error might also happen for
dynamic things by people who use the classes you designed. In that case
having this fatal error to stop the whole application can be annoying.
Opinions?
Derick
--
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] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Opinions? +1 Does that mean you want more opinions? :) regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote: Does that mean you want more opinions? :) Throw an InvalidArgumentException from SPL... -- Ondrej Ivanic ([EMAIL PROTECTED]) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Ondrej Ivanič wrote: Derick Rethans wrote: Does that mean you want more opinions? :) Throw an InvalidArgumentException from SPL... Won't work, SPL can be disabled. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans schrieb: Does that mean you want more opinions? :) No, I want a (InvalidArgument?)Exception to be thrown when I type-hint is not met. -- 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
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans schrieb: Won't work, SPL can be disabled. The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. -- 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
RE: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote:
Hei,
currently if you pass a wrong object's type to a typehinted parameter:
[...]
Fatal error: Argument 1 must be an instance of foo in /tmp/foo.php on
line 3
As type hinting is a new OO thing, it might perhaps make some sense to
make this an exception instead - as this error might also happen for
dynamic things by people who use the classes you designed. In that
case having this fatal error to stop the whole application can be
annoying. Opinions?
As a PHP user, I have to say I wholeheartedly agree, and I'm glad someone is
raising this issue again. The last time it was seriously discussed:
http://marc.theaimsgroup.com/?l=php-devm=104878782529499w=2
was less than encouraging.
As a user who is trying to write robust code, my biggest issue is not
whether or not a type hint violation throws an exception, but whether or not
it results in an error than I can trap for. An exception would be great,
obviously, but I'd be just as happy with an E_WARNING, so at the very least
my custom error handler can catch this. As you have pointed out, it's
currently a fatal error so a user-defined error handler is not called.
I don't typically comb through my server's php error logs, since I mainly
depend on my custom error handler to let me know when one of my applications
is having problems. Because of this I have been forced to avoid using type
hints and I've actually implemented by own function to simulate type hints,
like so:
/* @param SomeObject $foo */
public function someMethod($foo) {
checkArgType($foo, 'SomeObject');
}
checkArgType() throws an exception if $foo isn't instanceof 'SomeObject'.
I would MUCH rather use type hints here. They're cleaner from a
documentation standpoint and the wtf factor is much lower. Unfortunately I
can't as long as type hint violations are fatal.
So, I would be very happy if type hint violations either threw and exception
OR triggered an E_WARNING. As Wez pointed out in
http://marc.theaimsgroup.com/?l=php-devm=104911187824684w=2, currently if
you pass the wrong number of arguments to a function/method you get an
E_WARNING (not a fatal error), so I don't see why type hint violations
shouldn't be treated similarly. It would increase their value and utility
immensely...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote: As type hinting is a new OO thing, it might perhaps make some sense to make this an exception instead - as this error might also happen for dynamic things by people who use the classes you designed. In that case having this fatal error to stop the whole application can be annoying. Opinions? +1 on throwing an exception. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hmm,
I was complaining about inusaability ot type hinting because of this fatal
errors but nobody seems heard me :(. One better do a check in the code than
risking a fatal error which is unstoppable...
I call this showstopper if we say that we are proud with the type-hinting.
Andrey
Quoting Derick Rethans [EMAIL PROTECTED]:
Hei,
currently if you pass a wrong object's type to a typehinted parameter:
[EMAIL PROTECTED]:~$ cat /tmp/foo.php
?php
class foo {
function bar(foo $a)
{
}
}
$a = new foo;
$a-bar(new stdClass);
?
[EMAIL PROTECTED]:~$ php /tmp/foo.php
Fatal error: Argument 1 must be an instance of foo in /tmp/foo.php on
line 3
As type hinting is a new OO thing, it might perhaps make some sense to
make this an exception instead - as this error might also happen for
dynamic things by people who use the classes you designed. In that case
having this fatal error to stop the whole application can be annoying.
Opinions?
Derick
--
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] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Andrey Hristov wrote: Hmm, I was complaining about inusaability ot type hinting because of this fatal errors but nobody seems heard me :(. One better do a check in the code than risking a fatal error which is unstoppable... I call this showstopper if we say that we are proud with the type-hinting. Proof-of-concept patch is here: http://files.derickrethans.nl/patches/typehint-reference-2005-08-08.diff.txt (I need to clean up the message allocation stuff) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Sebastian Bergmann! On 08/08/05 13:32 you wrote: Won't work, SPL can be disabled. The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. Regards, -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say thank you?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Toby,
On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just sticking to Exception should be fine.
No it is not, in your application you can still simply catch Exception to be
independent of SPL since the InvalidArgumentException class extends the
Exception class. But by using nested Exceptions you can catch them
independently. Else you would have to catch every Exception, parse the error
message or trace to see wether it was a problem while calling the
function/method or some code inside the function/method went wrong.
?php
function foo() {
$bar = ;
try {
call_with_wrong_parameter($bar);
} catch (InvalidArgumentException $e) {
// bad function call...
}
}
try {
foo();
} catch (Exception $e) {
// any other exception
}
?
I'd like to see something like what Sebastian suggested. And imho it wouldn't
really be a bc-break since an uncaught exception is fatal, too.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Johannes Schlueter wrote: On Monday 08 August 2005 15:04, Tobias Schlitt wrote: The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. No it is not, in your application you can still simply catch Exception to be independent of SPL since the InvalidArgumentException class extends the Exception class. Throwing two different kinds of Exceptions is evil. It should be consistent, not relying on an external component for it's exceptions. So it will be a normal Exception. This is a useles branch of this tread - and it should end now. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Johannes Schlueter! On 08/08/05 14:50 you wrote: The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. No it is not, in your application you can still simply catch Exception to be independent of SPL since the InvalidArgumentException class extends the Exception class. But by using nested Exceptions you can catch them independently. Else you would have to catch every Exception, parse the error message or trace to see wether it was a problem while calling the function/method or some code inside the function/method went wrong. The point is, that it's senseless to have it throw any exception that can be disabled, when you want to write portable applications. In that case you still have to stick to catch Exception and have no benefit of it throwing anything else, when SPL is enabled. I would pretty much appreciate it having thrown an InvalidArgumentException, but then this should work everywhere. Regards, -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say thank you?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. -- 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
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. Not really. SPL is only for people that actually want to use Java. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005 15:09:06 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. Not really. SPL is only for people that actually want to use Java. Wrong, and this is a stupid argument, sorry. But this is another topic. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote: On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. Not really. SPL is only for people that actually want to use Java. I thought that's what exceptions are for (-:C Sorry, couldn't resist and I promise to shut up again, - Chris exceptions are only simple if you don't use them Schneider -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Tobias Schlitt wrote: Hi Johannes Schlueter! On 08/08/05 14:50 you wrote: The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. No it is not, in your application you can still simply catch Exception to be independent of SPL since the InvalidArgumentException class extends the Exception class. But by using nested Exceptions you can catch them independently. Else you would have to catch every Exception, parse the error message or trace to see wether it was a problem while calling the function/method or some code inside the function/method went wrong. The point is, that it's senseless to have it throw any exception that can be disabled, when you want to write portable applications. In that case you still have to stick to catch Exception and have no benefit of it throwing anything else, when SPL is enabled. I would pretty much appreciate it having thrown an InvalidArgumentException, but then this should work everywhere. I guess creating a new special exception (e.g. TypeHintException) that extends Exception as part of the php core (as opposed to living in SPL) is a stupid idea? IMHO btw, semantically, calling it S(tandard)PL and then making it so that it's not standard (i.e. it's an extension) seems odd. Regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 08 Aug 2005 15:56:55 +0200 [EMAIL PROTECTED] (Jochem Maas) wrote: IMHO btw, semantically, calling it S(tandard)PL and then making it so that it's not standard (i.e. it's an extension) seems odd. I was pretty sure until today that it was not possible to disable it. But it's not possible to build dynamicly. This is odd, to do not say stupid. What's about making really standard? Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Derick Rethans wrote: On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. Not really. SPL is only for people that actually want to use Java. Enabling it by default is same as enabling unnecessary bloat by default. So no thanks for making it not possible to disable.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello Tobias, Monday, August 8, 2005, 3:35:28 PM, you wrote: Hi Johannes Schlueter! On 08/08/05 14:50 you wrote: The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. No it is not, in your application you can still simply catch Exception to be independent of SPL since the InvalidArgumentException class extends the Exception class. But by using nested Exceptions you can catch them independently. Else you would have to catch every Exception, parse the error message or trace to see wether it was a problem while calling the function/method or some code inside the function/method went wrong. The point is, that it's senseless to have it throw any exception that can be disabled, when you want to write portable applications. In that case you still have to stick to catch Exception and have no benefit of it throwing anything else, when SPL is enabled. I would pretty much appreciate it having thrown an InvalidArgumentException, but then this should work everywhere. If you plan to support PHP builds without SPL then that most likley means that you have dropped other built-in default extensions too. Probably because of their memory space to reduce loading time. In that case you are not up for portability or have made a major mistake already in the beginning. Anyway there is no argument here. If you go for portable apps in the sense that any extension can be diabled then catching plain Exceptions should be more than good enough. You cannot expect to have full blown oo support when you disable the one oo extension. As a side note we could probably also move all exception declarations from SPL to the engine but then we'd loose the possibility to support builds without SPL. At the end of the day i'd even like to drop reflection support from the engine and move it to a specialized extensions - again - for speed/memory reasons. best regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello Derick, Monday, August 8, 2005, 3:09:06 PM, you wrote: On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. Not really. SPL is only for people that actually want to use Java. The stupiest thing you could have come up with. If it were about Java it was unusable and slow. You see t hat's the same bullshit and doesn't belong here - very contra productive. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hello Derick, Monday, August 8, 2005, 3:00:50 PM, you wrote: On Mon, 8 Aug 2005, Johannes Schlueter wrote: On Monday 08 August 2005 15:04, Tobias Schlitt wrote: The throw an Exception when SPL disabled and an InvalidArgumentException when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. No it is not, in your application you can still simply catch Exception to be independent of SPL since the InvalidArgumentException class extends the Exception class. Throwing two different kinds of Exceptions is evil. It should be consistent, not relying on an external component for it's exceptions. So it will be a normal Exception. This is a useles branch of this tread - and it should end now. Throwing a pure Exception is useless. Since it is the nature of Exception handling to code the reson into the Exception hierarchy. See my other reply and the comment on moving the exceptions to the engine. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Marcus Boerger wrote: without SPL. At the end of the day i'd even like to drop reflection support from the engine and move it to a specialized extensions - again - for speed/memory reasons. YES PLEASE! I've absolutely no use for it, and I really really need every bit of memory/speed/whatever I can get out of PHP.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Jani Taskinen wrote: without SPL. At the end of the day i'd even like to drop reflection support from the engine and move it to a specialized extensions - again - for speed/memory reasons. YES PLEASE! I've absolutely no use for it, and I really really need every bit of memory/speed/whatever I can get out of PHP.. Wow! Is PHP the right tool for you? If you don't use 00 things you can stay on PHP 4.x with ZE1. What you need/don't from PHP? It will be useful to move some parts of Exception hierarchy from SPL to ZE2, but from PHP 5.1 SPL it will be use full to move everything :) -- Ondrej Ivanic ([EMAIL PROTECTED]) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi all, Finally caught up with this thread. I can live with an exception being thrown for a type hint. I think calling it InvalidArgumentException would make sense, and the fact that Marcus stole :) that name for SPL and didn't prefix the name isn't a reason for us not to do the right thing... As it would be an engine exception, we'd move it to the Engine. This is a good reason why extensions such as SPL should prefix their functionality. As far as implementation is concerned, it definitely should wait for after PHP 5.1 and the patch should deal with the hard parts which are internal functions and overloaded functions. Implementing this for user-functions is the easier part. There might be some gotchas (as usual) with internal functions throwing exceptions. On a whole though, I do recommend to relax on the add-every-oo-feature-that-exists to the PHP code base, because it'll lead to PHP loosing its ease-of-use. The namespace proposal (which I haven't replied to yet) is a prime example. I saw all sorts of Java-like stuff like private classes which in my opinion would just over-complicate our model which already has become quite rich. We should only add what we really think PHP users need, and not stuff which is nice because it's OOpier. I do think that if we can get it right, a basic namespace model would be useful, but it all depends wether we can avoid the problems we had in the past *and* keep it simple! Andi P.S. - Derick, out of curiosity, what made you ask for an Exception? I thought you don't use OOP, and definitely not evil try/catch constructs? :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hey Marcus, What standard stuff? I remember SPL being used as a way to bring features to users which were decided not to have as standards :) Anyway, we won't get back into it as we've talked about it already in person. But anyway, if we decide to have InvalidArgumentException as a standard (which was not the case for most of SPL), then it definitely will make sense to move it to the Engine as the engine will need to know it. Features which make sense to remain as an SPL extension should be treated like a PHP extension. non-standard stuff shouldn't be prefixed to make me personally happy. I think it should be prefixed to make everyone happy, follow coding standards and follow the same rules as everyone. Andi At 11:43 PM 8/8/2005 +0200, Marcus Boerger wrote: Hello Andi, Monday, August 8, 2005, 11:33:16 PM, you wrote: Hi all, Finally caught up with this thread. I can live with an exception being thrown for a type hint. I think calling it InvalidArgumentException would make sense, and the fact that Marcus stole :) that name for SPL and didn't prefix the name isn't a reason for us not to do the right thing... As it would be an engine exception, we'd move it to the Engine. This is a good reason why extensions such as SPL should prefix their functionality. SPL delivers those standard stuff not delivered by the engine so it makes no sense to prefix them with an SPL prefix. Non standrd stuff will have SPL prefix in future though just to make you happy. Having said that i think that extension tree belongs either in the engine or stays in the extension and we go with pure Exception. Remember the reason i out this into SPL in the first place was to be able to drop all that fancy O stuff. In that sense i also asked to move reflection api into its own extension, that way adding another possibility to drop memory space of the excecutable, increasing exe load time and thereby increasing speed of such special builds. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
At 11:41 PM 8/8/2005 +0200, Derick Rethans wrote: On Mon, 8 Aug 2005, Andi Gutmans wrote: As far as implementation is concerned, it definitely should wait for after PHP 5.1 and the patch should deal with the hard parts which are internal functions and overloaded functions. Implementing this for user-functions is the easier part. There might be some gotchas (as usual) with internal functions throwing exceptions. Yeah, but afaik all cases *should* use this function 'zend_verify_arg_type', if not, that needs to be fixed. Yep, problem starts not when you identify and raise the exception but when you have to return to the engine and allow it to propogate. Andi On a whole though, I do recommend to relax on the add-every-oo-feature-that-exists to the PHP code base, because it'll lead to PHP loosing its ease-of-use. The namespace proposal (which I haven't replied to yet) is a prime example. I saw all sorts of Java-like stuff like private classes which in my opinion would just over-complicate our model which already has become quite rich. We should only add what we really think PHP users need, and not stuff which is nice because it's OOpier. I do think that if we can get it right, a basic namespace model would be useful, but it all depends wether we can avoid the problems we had in the past *and* keep it simple! Right, I definitely agree there. P.S. - Derick, out of curiosity, what made you ask for an Exception? I thought you don't use OOP, and definitely not evil try/catch constructs? :) I prefer not to comment on that :) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Derick Rethans wrote: On Mon, 8 Aug 2005, Andi Gutmans wrote: As far as implementation is concerned, it definitely should wait for after PHP 5.1 and the patch should deal with the hard parts which are internal functions and overloaded functions. Implementing this for user-functions is the easier part. There might be some gotchas (as usual) with internal functions throwing exceptions. Yeah, but afaik all cases *should* use this function 'zend_verify_arg_type', if not, that needs to be fixed. On a whole though, I do recommend to relax on the add-every-oo-feature-that-exists to the PHP code base, because it'll lead to PHP loosing its ease-of-use. The namespace proposal (which I haven't replied to yet) is a prime example. I saw all sorts of Java-like stuff like private classes which in my opinion would just over-complicate our model which already has become quite rich. We should only add what we really think PHP users need, and not stuff which is nice because it's OOpier. I do think that if we can get it right, a basic namespace model would be useful, but it all depends wether we can avoid the problems we had in the past *and* keep it simple! Right, I definitely agree there. P.S. - Derick, out of curiosity, what made you ask for an Exception? I thought you don't use OOP, and definitely not evil try/catch constructs? :) I prefer not to comment on that :) Derick Probably better a catchable exception than uncatchable Fatal error :) Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
