Lukas,
Ideally all libraries, be it PEAR or otherwise should always prefix
their class and function names, the one obvious prefix would be the
name of the library itself. For example when it comes to PEAR having
a pear_ (for functions) and PEAR (for classes) prefix would be perfect.
When it comes to PHP (the core) it should have complete freedom as
far as naming conventions (in the perfect world), but practically
prefix it with the extension name or abbreviation of it. Obviously
some exceptions need to be made for things inside ext/standard/
On 18-Jul-06, at 10:31 AM, Lukas Smith wrote:
Rasmus Lerdorf wrote:
I think we need to rename it. php_date or _date or something. I
don't really care what the name is, but I think we are too late in
the game to get the 'date' identifier. The other functions
enabled are fine and quite necessary actually. Both
timezone_abbreviations_list() and timezone_identifiers_list() are
quite useful.
This is a very key decision to make as we add new OO features, and
other abstract types. Does PHP reserve a right to claim obvious
identifiers or should PHP require from itself to namespace things
like this with a prefix (php_)?
Regardless what decision we make I think its high time that we
document what approach we want to take. A while ago I proposed such
a standard [1], but it obviously requires a decision from internals
to be of any merit. In the proposed document I gave PHP the right
to claim whatever identifiers it chooses, therefore pushing up the
responsibility of prefixing identifiers to end users (including PEAR).
regards,
Lukas
[1] http://oss.backendmedia.com/UserlandNamingGuide
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky
