Hi! > It is. > > I agree with your thoughts. > Back in 2008, namespaces were designed and added to PHP 5.3 as just > substrings in class names.
That is correct (except that namespaces first appeared in 2007, first commit f32ffe9b430b718628f868e449c1fcbdc8ec9ef6 if you're interested, of course were many since then that changed stuff :). However, I do not think what follows is. > That is not the right way to do things, but we had not that much time > to design them otherwise, and we did not want to break the API too > much by adding new structures. > So, namespaces were designed as "just" some substrings in class names, > with all the problems you spot. Designing namespaces as they are was a deliberate design decision, and it was not because we "didn't want to break APIs" or because we did not know better or were afraid of adding another struct, but because it was decided to choose a simple solution that allows to achieve a lot without introducing a lot of complexity. I certainly object to the blanket characterization of it as "not the right way to do things". I took part in the implementation and though it was almost 9 years ago, I think I still remember at least something :) We did consider using something like Java or Python packages, and we decided it's much too complex and not very suitable for dynamic world of PHP where classes and class files can be loaded at any time at any order. I think some people misunderstand this concept and think PHP namespaces are like half-baked Java packages but without some features because we were too short-sighted or too hasty to implement those. No, they are not like Java packages and they are implemented as not being separate entities but being name prefixes very consciously and deliberately. Now, 9 years later, we can reopen this question and think maybe our needs changed and maybe different model would serve us better. This is certainly possible and there's nothing wrong with that. But I think we need to approach it with right understanding of why we took certain decisions and where these decisions come from. It is very wrong to refactor something without understanding why it was built like that in the first place, and without understanding the initial design and requirements. We spent a real lot of time discussing all this stuff, and it'll be a pity if we spend this time again without using our previous experience. I also don't see any need in having "namespace registry", and, in fact, if you understand conceptual model of PHP namespaces as they are now, it doesn't make much sense to me. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
