Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
This is even better than requiring, and makes the intent very clear.
I don't think it decreases intuitiveness, on the contrary - from the
look of the code it is immediately clear which exception would be
used.
I went ahead and tried to apply
Right, it's not going to affect most classes most of the time, but my
point is that you can't predict which classes will be affected.
You can - set of internal classes is very well known, unless you are
using some exotic extensions.
In any case, I am not 100% happy with this solution, but th
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
... which is correct as far as it goes, there are no side effects.
However, if I flip the include order, including 1.php before 2.php,
then I get this:
Test::Exception
Test::Exception
Of course, since once Test::Exception is defined, Excepti
... which is correct as far as it goes, there are no side effects.
However, if I flip the include order, including 1.php before 2.php, then
I get this:
Test::Exception
Test::Exception
Of course, since once Test::Exception is defined, Exception in namespace
Test refers to it. It does not infl
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Except that it makes it unclear what happens in _other_ files, which is
In other files you specify what happens to other files.
even worse. Once you include the file above, any other file in the
Test:: namespace that throws an Exception will t
Except that it makes it unclear what happens in _other_ files, which is
In other files you specify what happens to other files.
even worse. Once you include the file above, any other file in the
Test:: namespace that throws an Exception will throw Test::Exception,
not Exception, even if it do
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
This is even better than requiring, and makes the intent very clear.
I don't think it decreases intuitiveness, on the contrary - from the
look of the code it is immediately clear which exception would be
used.
Except that it makes it unc
This is even better than requiring, and makes the intent very clear. I
don't think it decreases intuitiveness, on the contrary - from the look
of the code it is immediately clear which exception would be used.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zen
Chuck Hagenbuch wrote:
> So, if I want a "global" exception, I use ::Exception. If I say
> Exception, then I mean my namespace's Exception with no fallback. And
> if I want another namespace's Exception, I import it (import
> Other::Exception).
I (and PEAR) could live with this. I don't have a p
Quoting Gregory Beaver <[EMAIL PROTECTED]>:
Are you suggesting there be namespace-specific autoload? This sounds
interesting to me, but also quite complex, not sure the benefits would
outweigh the difficulties for implementation. For instance, PEAR2
namespace would be different from PEAR2::Som
Chuck Hagenbuch wrote:
> Hi folks-
>
> I've hit upon something with namespaces and autoloading that I think is
> a little out of order. If you take the attached 3 files, put them in the
> same directory, and run demo.php, you will see this:
>
> Fatal error: Uncaught exception 'Exception' in
> /Us
11 matches
Mail list logo
