+1 for putting namespaces on the backburner and taking the time to get it 100% right ...
Stanislav Malyshev wrote: >> some people like a "misguided" implementation of namespaces. The idea >> of namespaces is to prevent collisions in USER land code, not turning >> internal PHP classes into a pile of goo. > > Yes, idea of namespaces is not to turn PHP classes into a pile of goo. > But what's your point? > >> I don't quite understand why allowing multiple namespaces is such a >> big issue, however - it won't solve the naming collision issue. > > I'm sorry, I don't understand what you mean by "multiple namespaces" - > multiple namespaces per file? I object to allowing it for reasons having > absolutely nothing to do with naming collisions, as anybody bothering to > actually read what I wrote would immediately know. this implies that your objections to multiple namespaces per file is valid whereas objections to the limitation are invalid. apparently people keep 'flogging this horse to death' because they are not convinced by your wisdom with regard to this decision - they may be idiots (me included) but they are the majority of your users, so it seems. > >>> That's because namespaces are not executable blocks. >> >> Neither are classes. > > Your point being? that therefore your argue that "namespaces are not executable blocks" doesn't hold up unless your willing to state the inconsistency is one of your design goals. > >> No, but, do you really need to have such long names? And besides that, > > Yes. Such names are hard fact of life, I have seen them in many > applications and libraries, and I have heard developers to complain > about it. <remark type="OT" class="irrelevant"> developers will complain, it's in their blood, nothing anyone will ever produce will change that ... somewhere in the future when all code is created without the intervention of man .. even then there will still be a compiler complaining. </remark> > >> you *have* to keep repeating them in every file you'd want to use them - > > Once per file, yes. Much better than having to spell out all the long > names every time. > > > Just saying "Yes, they are" is not a very good argument - actually, it's >> not an argument at all. > > No more and no less than "I wonder if they are useful, let's just delete > them". actually that is not true - a halfbaked concept is pretty much garanteed to give you and the users of your product more headaches than no implementation at all. and once the genie is out of the bottle your stuck with it - with all the BC implications of having to support functionality people would rather see changed. besides possibly having to type a little less, there seems to be nothing namespaces would give us [in it's current form] that we cannot achieve already ... with the bonus that users are currently not restricted in the way they organize/rollout their code, at least with regard to 'bundling' of files. > >> Actually, it's exactly the opposite, as I avoid naming colissions >> (point 1), I don't need to import every class I want to use (point 2), >> and can group all my classes together in one file (point 3). > > Of course, if you don't want to hear about namespaces, nobody can force > you. However, all of your points (avoiding naming collisions, not > needing to import every class you want to use and ability to group > classes together) is exactly how namespaces work right now. If you > refuse to learn about it, it can't be helped, however that just means > you deny yourself a very useful tool. conversly - when namespace functionality is released, every developer will be confronted with any problems they might bring with them, at some stage, because there will be third party code out there that uses namespaces (code which for the sake of argument one would be required to use under some circumstances). > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
