Hi!
Christian Schneider wrote:
> leads to another inconsistency: Depending on the hosting provider and/or
> frameworks/modules used you'd have to write different error handlers.
I understand there are widely differing applications for php, that's why
I think backwards-compatibility and common defaults across installations
is a must. Changing defaults system-wide is always risky. In a
shared-hosting situation, the proposed error defaults *must not* be
changed, of course.
However, there are also many single-hosted applications that could
benefit greatly from configurability.
And note I don't only write pro global-configurability, but also
object-wise, like:
$T = new TranslationReader(...);
// say, on error, $a gets set to NULL, no error issued
$a = $T->get('nonexisting');
// change that behaviour for $T ONLY
$T->setErrorBehaviour( ERROR_THROW );
try {
// if ANY error in $T occurs, a corresponding exception is caught
[read many many translation strings]
}
catch( Exception $e ) {}
> One of the nice things about PHP it's easy to learn and knowledge & code
> is (most of the time) transferable amongst different instances of PHP.
And that's how it shall always be. I believe it should even give more
structure in a field where extensions currently fragment and render
php more complicated than it had to be.
Regards
HPO
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
