Re: AW: [PHP-DEV] Namespace resolution

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 globa

Re: AW: [PHP-DEV] Namespace resolution

Calm down David :) He is referring only 3 cases. Please check the link he is providing too :)

AW: AW: [PHP-DEV] Namespace resolution

> 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

[PHP-DEV] Re: Type hinting

Sam Barrow schrieb: What is the general opinion on this? I am all for it. And i think you (or someone else) had it combined with overloading, wich would be a quite nice extra benefit. -- Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.n

Re: [PHP-DEV] Re: Type hinting

On Dec 11, 2007 3:05 PM, Sam Barrow <[EMAIL PROTECTED]> wrote: > 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. http://pecl.php.net/package/params http://pecl.php.net/package/SPL_Types Could you please sho

[PHP-DEV] Re: Type hinting

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 p

[PHP-DEV] Re: Type hinting

Sam Barrow schrieb: > What is the general opinion on this? I'm all for it. Would be using it already, if it where available as an extension. Do i recall right, that you (or someone else) had this combined with overloading? -- Chris -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] Type hinting

Sam Barrow schrieb: > A few weeks ago I wrote a message on this list Please do not start a new discussion by replying to a posting that belongs to a previous thread. This, too, has been written on the list. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key:

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: [PHP-DEV] Type hinting

-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: >

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

AW: AW: [PHP-DEV] Namespace resolution

> 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

Re: AW: AW: [PHP-DEV] Namespace resolution

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

[PHP-DEV] namespace improvements to be committed very soon - final review

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: The example above shows that imported names a

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: [PHP-DEV] namespace improvements to be committed very soon - final review

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 namespaces per file > 2) use ::name; > > 1) multiple namespaces per f

Re: AW: [PHP-DEV] Namespace resolution

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

Re: [PHP-DEV] namespace improvements to be committed very soon - final review

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. > > > >

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: AW: [PHP-DEV] Namespace resolution

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

Re: [PHP-DEV] namespace improvements to be committed very soon - final review

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

Re: [PHP-DEV] namespace improvements to be committed very soon -final review

Sam Barrow wrote: > Is this patch going to be implemented in the PHP release? yes, these are patches against cvs.php.net php5 -r PHP_5_3 and HEAD Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] namespace improvements to be committed very soon - final review

On Dec 11, 2007 6:13 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote: > The example above shows that imported names are reset at each namespace > declaration. There is no prohibition on this code: > > namespace one; { > use Blah::A; > // code > } > namespace two; { > use Foo::A; > // code > } > ?>

Re: [PHP-DEV] namespace improvements to be committed very soon - final review

Ken Stanley wrote: > > > On Dec 11, 2007 6:13 PM, Gregory Beaver <[EMAIL PROTECTED] > > wrote: > > The example above shows that imported names are reset at each > namespace > declaration. There is no prohibition on this code: > > namespace one; { >

[PHP-DEV] Idea for namespace lookup resolution

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 __

[PHP-DEV] Re: Idea for namespace lookup resolution

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_classe