Lukas Smith wrote:
Marcus Boerger wrote:
That conclusion means stay with date in ext/date and have pear learn the
lesson by making the same mistake in core. Once again the only
solution is
namespacing.
indeed.
though this "mistake" applies to all of PEAR at this point ..
As has been pointed out before this isn't only a PEAR problem: Every
single application out there defining a Date class has to be changed if
the core adds a class with the same name.
Is this common? One of our running gags here is that every project ends
up adding its own set of date formating/conversion functions/classes at
some point. So unless people are prefixing all local classes there is a
rather good chance of having a class named Date in quite some projects.
Section [7] of CODING_STANDARDS Naming Conventions states that "The
class name should be prefixed with the name of the 'parent set'" but at
the same time lists "Curl" as good. Now my question is whether the
prefixing should be enforced (at least when a common name like Date is
used)?
Or
a) am I missing something
b) is it the core developers' opinion that core classes have the right
of way?
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
