2008/11/4 Andrey Hristov <[EMAIL PROTECTED]>
> Ryan Panning wrote:
>
> use 'NsA\NsB\NsC\func_c()';
>>
>
> OMG That looks UGLY1
>
This is exactly the kind of comment that is both useless and pointless.
Could you please make sure that you have a valid point with a subject,
arguments, e
Ryan Panning wrote:
use 'NsA\NsB\NsC\func_c()';
OMG That looks UGLY1
$obj = new NsA\NsB\ClassB;
$obj->methodB();
func_c();
?>
Best,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
First, I want to say thanks for determining the best separator. Even
though it's not what everyone would like, it's what would work best.
Second, sorry for starting a new thread. To me, continuing the
resolution discussion in the "namespace separator and whining" isn't the
correct place.
Thi
> > Just a quick idea - what if requiring that autoloaders behave
> > deterministically, that is, once a certain autoloader
> > implementation
> > has been given the possibility to find a class it will
> > never be asked
> > again (because it wouldn't find it later on either).
>
> I'm not s
Just a quick idea - what if requiring that autoloaders behave
deterministically, that is, once a certain autoloader implementation
has been given the possibility to find a class it will never be asked
again (because it wouldn't find it later on either).
I'm not sure if it's a correct assumption
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> If the class for which autoloaded request is issued *exists*.
> However, we are discussing the case where this class *does
> not exist*, so it can not be loaded. Thus, autoload request
> will be repeat
And didn't you say "use" is a NOP just two hours ago?
No, I didn't. I said "use whatever;" - where "whatever" is one-term name
- is a NOP.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runt
Stas, please. It is preventing disk access in case the file to be loaded
is not from my namespace. If it is from my namespace, and I as an
autoloader was called, what am I gonna do? require() it of course, what
else? My point was that if you have ten autoloaders registered, and the
If the cla
Am 12.12.2007 um 01:04 schrieb Stanislav Malyshev:
Why? I did import Name::Space. According to the current lookup
rules, the first new DateTime() call creates a PHP internal class
since Name::Space::DateTime cannot be found (and autoloading would
only be triggered later), and the second Dat
Am 12.12.2007 um 01:02 schrieb Stanislav Malyshev:
Look. If you have an autoloader for Your::Namespace, then you just
need to check if the class name (which is fully qualified, with the
entire namespace prefix in the name) starts with "Your::Namespace"
to prevent disk access.
How this pre
Why? I did import Name::Space. According to the current lookup rules,
the first new DateTime() call creates a PHP internal class since
Name::Space::DateTime cannot be found (and autoloading would only be
triggered later), and the second DateTime() call does create
Name::Space::DateTime because
Look. If you have an autoloader for Your::Namespace, then you just need
to check if the class name (which is fully qualified, with the entire
namespace prefix in the name) starts with "Your::Namespace" to prevent
disk access.
How this prevents disk access, I don't understand? So, it does start
Am 12.12.2007 um 00:27 schrieb Stanislav Malyshev:
require_once('setup.php');
import Name::Space;
$d = new DateTime(); // a PHP DateTime
someStuffWeDoNotHaveControlOver();
$d = new DateTime(); // a Name::Space::DateTime now!
Of course not. DateTime would be just DateTime there, not
Nam
Am 12.12.2007 um 00:24 schrieb Stanislav Malyshev:
namespace Name::Space;
class Ship {
public static function __autoload($className) {
if(strpos($className, 'Name::Space::') === 0) {
// the real deal
}
}
}
...
spl_autoload_register(array('Name::Space::Ship', '__autoload'));
No disk
David Zülke schrieb:
Let's assume we have ten autoloaders. We are, by import, in namespace
Name::Space. Someone does new DateTime();
You would now have to go through all ten autoloaders before you can
decide that no userspace class DateTime exists in any namespace, and
thus the PHP internal c
require_once('setup.php');
import Name::Space;
$d = new DateTime(); // a PHP DateTime
someStuffWeDoNotHaveControlOver();
$d = new DateTime(); // a Name::Space::DateTime now!
Of course not. DateTime would be just DateTime there, not
Name::Space::DateTime, since you are not inside name
namespace Name::Space;
class Ship {
public static function __autoload($className) {
if(strpos($className, 'Name::Space::') === 0) {
// the real deal
}
}
}
...
spl_autoload_register(array('Name::Space::Ship', '__autoload'));
No disk access. And with my suggestion to allow lim
Matthias Pigulla wrote:
>> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
>
>> But you could achiever the same just by avoiding naming classes the
>> same as internal classes, you surely know which classes are in your
>> own namespace?
> ...
>> Not using names of classes same as internal classe
> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> But you could achiever
> the same just by avoiding naming classes the same as internal classes,
> you surely know which classes are in your own namespace?
...
> Not using names of classes same as internal classes is not a big deal
> either - a
Am 11.12.2007 um 23:36 schrieb Stanislav Malyshev:
import Name::Space;
// only stuff from Name::Space available, no PHP internal stuff
import __php__;
// now PHP's classes are loaded, too.
So "import php" make internal classes always take priority even when
there's a class in this namespace
Am 11.12.2007 um 23:38 schrieb Stanislav Malyshev:
A simple
if(strpos($className 'My::Namespace::') === 0)
will fix that just fine.
Fix what? If you write:
namespace My::Namespace;
function foo() {
$a = new DateTime();
}
then on each call to foo() autoloader for My::Namespace::DateTi
A simple
if(strpos($className 'My::Namespace::') === 0)
will fix that just fine.
Fix what? If you write:
namespace My::Namespace;
function foo() {
$a = new DateTime();
}
then on each call to foo() autoloader for My::Namespace::DateTime would
be called, then it would go to disk and s
import Name::Space;
// only stuff from Name::Space available, no PHP internal stuff
import __php__;
// now PHP's classes are loaded, too.
So "import php" make internal classes always take priority even when
there's a class in this namespace by that name? But you could achiever
the same just by
Am 11.12.2007 um 22:31 schrieb Stanislav Malyshev:
You would now have to go through all ten autoloaders before you can
decide that no userspace class DateTime exists in any namespace,
and thus the PHP internal class DateTime may be used.
Even one autoloader is bad enough to not even have to
Am 11.12.2007 um 22:31 schrieb Stanislav Malyshev:
You would now have to go through all ten autoloaders before you can
decide that no userspace class DateTime exists in any namespace,
and thus the PHP internal class DateTime may be used.
Even one autoloader is bad enough to not even have to
Stanislav Malyshev wrote:
>> You would now have to go through all ten autoloaders before you can
>> decide that no userspace class DateTime exists in any namespace, and
>> thus the PHP internal class DateTime may be used.
>
> Even one autoloader is bad enough to not even have to consider the case
You would now have to go through all ten autoloaders before you can
decide that no userspace class DateTime exists in any namespace, and
thus the PHP internal class DateTime may be used.
Even one autoloader is bad enough to not even have to consider the case
of ten autoloaders. Remember, autol
Am 11.12.2007 um 21:22 schrieb Stanislav Malyshev:
Ah. Yes, that makes perfect sense to me. The logical solution must
be then, however, not to implement namespaces at all, or requiring
code
It's not a solution, it's refusing to solve a problem.
Well, if your answer is that it makes sense
Ah. Yes, that makes perfect sense to me. The logical solution must be
then, however, not to implement namespaces at all, or requiring code
It's not a solution, it's refusing to solve a problem.
for the behavior from an implementational standpoint, but I think it
really is obvious that such a
Am 11.12.2007 um 19:00 schrieb Stanislav Malyshev:
The problem I see with that is that if I have an application that
uses a 3rd-party library which does not use namespaces, I need to
use ::LibClass everywhere. Until they switch to namespaces - then I
need to touch hundreds and thousands lin
The problem I see with that is that if I have an application that uses a
3rd-party library which does not use namespaces, I need to use
::LibClass everywhere. Until they switch to namespaces - then I need to
touch hundreds and thousands lines of code. If LibClass were looked up
in the global na
> Von: David Zülke [mailto:[EMAIL PROTECTED]
> The problem I see with that is that if I have an application that uses
> a 3rd-party library which does not use namespaces, I need to
> use ::LibClass everywhere. Until they switch to namespaces - then I
> need to touch hundreds and thousands lines of
Calm down David :) He is referring only 3 cases. Please check the link he is
providing too :)
David
Am 11.12.2007 um 08:31 schrieb Matthias Pigulla:
-Ursprüngliche Nachricht-
Von: Sam Barrow [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 10. Dezember 2007 22:48
An: internals@lists.php.net
Betreff: [PHP-DEV] Namespace resolution
Ok, it's supposed to be this way right? If
> -Ursprüngliche Nachricht-
> Von: Sam Barrow [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 10. Dezember 2007 22:48
> An: internals@lists.php.net
> Betreff: [PHP-DEV] Namespace resolution
>
> Ok, it's supposed to be this way right? If i define a custom class
Ok, it's supposed to be this way right? If i define a custom class in
the global namespace called "myClass" and I'm in another namespace, I
can only access it using ::myClass, not just myClass (without the
colons)? Seems to me that it should check the local namespace and then
the global, but it onl
36 matches
Mail list logo
