Hi all, Since we have discussion for Next PHP, "PHP" namespace discussion would be nice to have.
Currently, PHP module functions/classes/interfaces are using global(root) namespace. If it is changed to use its own namespace, user space APIs may be changed flexible and user controlled manner. Thus, PHP may have - Consistent naming - Consistent parameter order - Graceful function/class/interface deprecation (We know what we should do for these, right?) without much compatibility issues. "PHP" namespace may be used to provide PHP(and 3rd party) functions/classes/interfaces/constants. "PHP\Legacy" (or whatever) may be used for legacy functions/classes/interfaces/constants. >From PHP 5.6, userland function aliasing can be done with namespace. Following code overrides existing function. <?php use function \mb_strlen as strlen; var_dump(strlen('日本語')); ?> Result: int(3) It's good to use prefered API, but it requires "use" for every function APIs to be overridden. Note: Classes/Interfaces may override by "use" one by one also. With "PHP" and "PHP\Legacy" namespace, user may write: <?php namespace PHP; // Use current PHP functions/classes/interfaces/constants // Code uses current API ?> <?php namespace PHP; namespace PHP\Legacy; // Override with legacy PHP functions/classes/interfaces/constants. // Code uses legacy API ?> For compatibility, default namespace setting would be nice to have. - None for compiled default - "PHP" for php.ini-* Previous example codes became: <?php // Code uses current API ?> <?php namespace PHP\Legacy; // Override with legacy PHP functions/classes/interfaces/constants. // Code uses legacy API ?> Issue would be codes that assume PHP functions/classes/interfaces/constants are defined in global(root) namespace. (e.g. \strlen()) This could be workaround by allowing "use" aliasing to global(root) namespace. (e.g. "use PHP\Legacy as \;") In this case, current functions/classes/interfaces may stay in global(root) namespace. (or "use PHP as \;") Programmers may shoot their own foot by this. This is the trade off of flexibility. Any thoughts and/or comments? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net