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
[email protected]
