Then the name of the extension is wrong.
Well, that's what we could do. You are welcome to propose a better one :)
But this way we get an overflow of prefixes. And I'd prefer grouped functionality to share prefixes.
We don't have any limit on how many prefixes we can have, so I don't see any reason why extension can't have more than one, provided it's warranted by it's structure - i.e. having more than one distinct functional module. Again, the practical purpose of this is to avoid naming conflicts. I think we can agree numfmt_*, etc. achieve that. And actually CODING_STANDARDS never says function prefix should be extension name - it only says functions should use prefixes and provides extension name as an example of class prefix. What it actually says is:
"If they are part of a "parent set" of functions, that parent should be included in the user function name, and should be clearly related to the parent program or function family. This should be in the form of parent_*:"
I think right now intl/ extension conforms to it fully - each parent set has its own prefix.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
