On 05.12.2007, at 17:43, Sebastian Bergmann wrote:
Matthias Pigulla schrieb:
Given that it was technically feasible, (future) core classes should
be in namespaces as well.
Or
- Introduce namespaces in PHP 6
- Move all functions and classes that are now global into
(per-extension) names
This would be a good idea, if implemented with a compatibility layer to
be removed later.
::php
::str
::arr
::ob
etc
::ext
::mysql
::mysqli
Userland code can then use a namespace such as ::app, or just use the
global namespace with no worrie
Matthias Pigulla schrieb:
> Given that it was technically feasible, (future) core classes should
> be in namespaces as well.
Or
- Introduce namespaces in PHP 6
- Move all functions and classes that are now global into
(per-extension) namespace(s)
- Add a fallback mechanism that looks
> Von: Steph Fox [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 5. Dezember 2007 02:34
> import nstest::test as whatever;
>
> This works in the global space, right? Now along comes, say, Pierre or
> Derick or Marcus with this class they just have to add to an existing
> (non-namespaced) core ext
Hello Steph,
Wednesday, December 5, 2007, 2:33:47 AM, you wrote:
>>> However, in the global scope (no namespace) it would fail. This is a
>>> bug that is easily fixed. use should allow re-aliasing of global
>>> classes, and I could provide a very easy fix.
>>
>> This is not a bug - since there
I don't understand what are you going to demonstrate with this example.
Did you try to run it?
It produces error as expected.
DOMDocument() in your example is a user-space class that is not related
to internal ext/dom class. If you like to use internal class that is
overriden in namespace you c
On Tue, 4 Dec 2007, Gregory Beaver wrote:
> However, in the global scope (no namespace) it would fail. This is a
> bug that is easily fixed. use should allow re-aliasing of global
> classes, and I could provide a very easy fix.
No, use should not allow this. Take the following example:
loadXML
On 05.12.2007, at 04:28, Steph Fox wrote:
I'd like wildcard support too... and support for multiple namespaces
per file (for bundling only)... but neither of those are complete
deal-breakers in my eyes. Protection from naming collisions, is.
FULLACK, the good news is that i accidently mail
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
And now I've finished reading old South Park episodes...
OK, it's sinking in now. Because global import/use is
I can't. I can only hope they would do it right, I can't force them to do
it right :)
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
Maybe one of the OO gan
sense again. But Stas, consider (old dialect bc I need to update locally
sorry):
import nstest::test as whatever;
This works in the global space, right? Now along comes, say, Pierre or
Right.
Derick or Marcus with this class they just have to add to an existing
(non-namespaced) core extens
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global spac
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global spac
I used import in my last example instead of use, that was simply a typo,
not trying to open a can of worms.
Sorry,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
> With all the above considerations, especially my first point, I still have not
> heard any good reason why namespaces in the current implementation are
> actually
> useful - or what particular case they solve... so I am wondering, are they
> really useful? I come now to th
15 matches
Mail list logo
