Ilia Alshanetsky wrote:
Defining classes/function with generic names will always be a problem as they may end up conflicting with same constructs from other libraries or PHP itself.
Sure. But that doesn't change the fact that a class named date is *known* to cause conflicts. And that the core has a higher responsibility than any extension/library/package IMHO.
To design future proof code projects for the most part prefix all their functions/classes to prevent naming conflicts.
Had a quick glance at Gallery2 because it was lying around and they don't consistently prefix things. Most classes are prefixed but not all of them. I'm inclined to believe that's the case for most popular packages, let alone everything else.
It makes little sense to have a class called curl_curl, when it comes to functions the coding standard applied and all functions have a prefix.
That's why I wrote "... (at least when a common name like date is used)". While Curl is unique enough (although I'd rather have a longer name for the sake of a uniform naming scheme) the name date will *definitely* be causing problems. We all agree on that I think.
The question is only if you shift the responsibility to PHP developers (a mere dozen people could decide to change it) or to PHP users (thousands, not even aware of the issue).
Signing out of this thread with a plea for pragmatism, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
