Stanislav Malyshev wrote:
>> namespace Foo;
>> import Exception;
>
> Once more, import with one-term argument is a no-op. And will stay so.
> That's why we have the warning.
>
>> I think that either import ::Exception needs to work, or import
>> Exception shouldn't issue a warning.
>
> We'll discus
namespace Foo;
import Exception;
Once more, import with one-term argument is a no-op. And will stay so.
That's why we have the warning.
I think that either import ::Exception needs to work, or import
Exception shouldn't issue a warning.
We'll discuss this one. I wonder if anybody else feel
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Yes. I think that if you use an unqualified name it should always
be relative to the namespace (and importing internal classes into
your namespace lets you use short names for them, avoiding
::Exception).
Unfortunately, there are problems wi
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
import Exception;
-> name conflict, which seems correct
import Exception is a no-op, so I don't understand how you could
have got name conflict. Do you mean "import Test::Exception"? That
should work, if it didn't it's a bug.
It turns out t
Yes. I think that if you use an unqualified name it should always be
relative to the namespace (and importing internal classes into your
namespace lets you use short names for them, avoiding ::Exception).
Unfortunately, there are problems with this solution, since it
makes common case harder to
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
I'm not sure I follow you. If you intend to always use internal one,
why you define the local one? If you sometimes intend to use one and
sometimes another - I propose you a way to ensure the right one is
always used, this without using potent
I don't think this helps; it means that you need to use the local syntax
every time you use a class, instead of importing it once, and it doesn't
resolve the fact that if you use a non-fully-qualified classname (like
Directory, for a different example), you need to say ::Directory or else
if a
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
"import PHP" is a no-op now. However, I have another idea about it
(besides the fix for the import thing that indeed looks like a bug
to me) - what if we add some syntax to say "use this namespace"
which would use autoload, so you'd say:
nam
builtin classes is feasible, but if it is, then the simple, "put global
classes into my namespace" ("register_globals" ;) option is:
namespace Test;
import PHP;
"import PHP" is a no-op now. However, I have another idea about it
(besides the fix for the import thing that indeed looks like a bu
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
But you shouldn't even look for Exception then. I'm saying that if
you want the global Exception class you should import it.
That would be double bad - that means you have to go over all your
code and add :: to all instances of global classes,
But you shouldn't even look for Exception then. I'm saying that if you
want the global Exception class you should import it.
That would be double bad - that means you have to go over all your code
and add :: to all instances of global classes, even though you never
ever intended to override an
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Because if you say "Exception" inside any namespace, we should check
if Foo::Exception not exists anywhere, which means full search of
all autoloading possibilities. Only after we ensured that no such
class exists anywhere, we might use Except
my own namespace. And the fact that changes to what classes PHP provides
can change the order of class resolution seems like unnecessary
fragility to me.
I agree that it is not ideal way for all setups, however the alternative
is worse - it leads to more problems.
I am not understanding why
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Not entirely correct - namespaces needed to reconcile _multiple_
libraries, while in case of Exception you need to stay away only
from _one_ set of classes - namely, internal ones. While indeed even
that could be inconvenient, the problem is t
Calling exception classes something other than Exception is kind of like
giving up on the namespace - if I have to name my classes, *inside*
Not entirely correct - namespaces needed to reconcile _multiple_
libraries, while in case of Exception you need to stay away only from
_one_ set of clas
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
If it worked this way, you couldn't easily use global classes and
old applications would be much harder to convert to namespaces. We
think that using global Exception is much more frequent than
defining your own Exception - and in the latter c
::Exception, because the class resolution order seems to look like this:
- does the class exist (_already defined_) in the current namespace?
- does the class exist in the global (non-prefixed or "::") namespace?
- then try autoload
That's exactly how it works, with the amendment that only inte
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 /Users/chuck/Desktop/test.php:7
If
18 matches
Mail list logo
