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
Calm down David :) He is referring only 3 cases. Please check the link he is
providing too :)
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
I didn't do anything with overloading, just this.
Also, due to its functionality, it's not something that can be made into
an extension, it would have to go directly into the php source.
I have the patch if you want it, let me know. I've been using it for
almost a month now with PHP 5.3 with no
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For the record, I'm all for it. Optionality means flexibility. If one
doesn't want to use it, he doesn't have to.
Can you send a patch against 5.3 in CVS?
Have you thought about type hinting for return values?
thanks,
- - Markus
Sam Barrow 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
of ten autoloaders. Remember,
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
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 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
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
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 - all
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 classes is not a
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.
1) multiple namespaces per file
2) use ::name;
1) multiple namespaces per file
This is implemented as such:
?php
namespace one;
use Blah::A;
// code
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
example.php
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
On Dec 11, 2007 6:42 PM, David Coallier [EMAIL PROTECTED] wrote:
On Dec 11, 2007 6:13 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.
1) multiple
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
Am 12.12.2007 um 00:27 schrieb Stanislav Malyshev:
example.php
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
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
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
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
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
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
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 Runtime
Is this patch going to be implemented in the PHP release?
On Tue, 2007-12-11 at 18:42 -0500, David Coallier wrote:
On Dec 11, 2007 6:13 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to
I just thought of something that might be a solution to the lookup rules
that we currently have in the namespaces implementation. Whether it's
good or not, I just wanted to throw it out there. Here goes:
Support a user-defined function named __get_namespace_classes, which
will be similar to
Jessie Hernandez wrote:
I just thought of something that might be a solution to the lookup rules
that we currently have in the namespaces implementation. Whether it's
good or not, I just wanted to throw it out there. Here goes:
Support a user-defined function named __get_namespace_classes,
30 matches
Mail list logo
