Stanislav Malyshev wrote:
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users
with autoload (and long include path lists).
I think silent performance disaster is much worse than error message
which makes it obvious what the mistake was.
Me too. This is the problem I am referring to:
a.php:
<?php
namespace Foo;
class Exception {}
?>
b.php:
<?php
namespace Foo;
class A {
function __construct() {throw new Exception('hi');}
}
?>
c.php:
<?php
function autoload($a)
{
include 'a.php'; // bogus, but you get the point
}
include 'b.php';
try {
$a = new Foo::A;
} catch (Foo::Exception $e) {
echo "caught\n";
}
?>
The above code will throw an ::Exception, not a Foo::Exception. With
the proposed change, it works as advertised. This code:
<?php
include 'a.php';
include 'b.php';
try {
$a = new A;
} catch (Foo::Exception $e) {
echo "caught\n";
}
?>
throws a Foo::Exception and echoes "caught", demonstrating the
importance of load order as well.
This is *far* from an obvious error message, it is a silent logic error
that is far more serious than a silent performance problem.
Stas, your response is quite frustrating to this problem and fits a
pattern. It seems the default response is always "no" or "that's not a
real problem" and is almost always condescending. It makes it extremely
difficult to have an intelligent debate with you. If you don't think
something is a real problem, perhaps a better default response is "why
does this person think it is an issue and I don't?" The impression your
response gives is that your first thought is instead "why is XXX such an
idiot who must waste my time?" I know you well enough to know that this
is not what you're thinking, but it would save a lot of time if we can
skip the "what the hell" stage and move right to "let's verify this and
fix it" or "more evidence needed, I see your point but what about XX?"
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
