Hello Christian,
here again namespaces would be perfect. Given a lib that doesn't prefic
you'd simply d:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
regards
marcus
Friday, November 25, 2005, 2:14:10 PM, you wrote:
> 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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
