Hi!
I disagree. The idea is that I get control over how I manage to global namespace. As such its sensible that I want to use "mysql" in my code instead of DB::mysql.
You may use it. You just won't get wildcard imports, because that doesn't work conceptually.
Also when it comes to resolution, inclusion order should not matter, period. if it does we have a serious flaw in our design. if we cannot
We already have this serious flaw in our design. If we use "new Foo()", and it's definition not included, it resolves differently (namely, to fatal error) than if we had included the definition. Also, with inheritance, if you include or define inherited classes in wrong order - i.e. child before parent - you may get problem too. You'd say this can be changed by autoloading, moving classes around, etc. - but behavior you complain about can be changed easily too, you just insist there would be no possible case, however hard you try to make a mistake, to get different resolution.
make a performant solution in this case, we better have nothing. that
I don't see how it's better to have nothing at all than a solution that works in 99% of cases - unless you try on purpose to write code that doesn't work. I also find it very strange that you and other people are so insistent on having no namespace solution at all. How that would help you? How that would make PHP better?
if some core developers have extensive experience with namespaces in Java and packages in other languages, these people have done more with this construct in PHP than many of us have. Also while I do not know all
You seem to suppose neither me nor people I talked with didn't try to do things with namespaces in PHP. This is not correct.
that they are solid developers. So I think you are brushing their expectations off too lightly here.
By "brushing too lightly" you mean "spending three days in discussion, explaining repeatedly point by point each decision and each tiny point of each argument, in full detail", right?
I am not a friend of smarty, but for one most template engines work very hard to keep the number of chars to a minimum in order to not "pollute" their markup with too much PHP code (just think of the <?= camp or
I remember all <?= proposals were shut down with cries of "we don't need no stinkin shortcuts!". I was told that PHP should be clean and there's nothing wrong with typing a bunch of characters if it makes things clear. So I left the <?= thing alone - only to get it back as an argument against me!
The fact that people expect that they can call a function from a namespace in a way that looks different from a static method call however is imho clearly something that needs to be addressed. One way
I don't see why they have to insist on that. I think it's just misconception, making artificial differences where they do not exist.
I am not convinced that you have demonstrated the mentioned used cases are really so clearly "the wrong way" that they should not be supported.
What could convince you that something is a wrong way, theoretically? I showed that it has hight WTF factor, can lead to potential bugs, and does not add anything to functionality. So far strongest argument for them I got is "I don't want :: in names". For me, "don't want :: in names" versus "buggy unmaintainable code" is clearly wrong way. But some think otherwise, that's their right.
I think that PHP is not an OO language and as such there is no reason to
Namespaces is an OO feature, however. It is only natural that if you don't want to touch OO, you get no namespaces. PHP has tons of features that make sense only if you use OO, that's one more of them.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
