On Tuesday 04 December 2007, Derick Rethans wrote:
> 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> 'namespaces'. We could optionally create a registry on php.net for
> this to avoid conflicts.
Although most people on the list seem to be coming at this problem assuming
classes, I want to offer a counter-example that is all functions.
In Drupal, our plugin architecture is based on function naming. When a given
event "omg" occurs, something akin to the following frequently happens (a bit
simplified):
$hook = 'omg';
foreach ($modules_that_are_loaded as $module) {
$function = $module .'_'. $hook;
if (function_exists($function)) {
$return[] = $function();
}
}
return $return;
It's a very powerful mechanism, and quite flexible. The one thing it doesn't
offer is, given a function name, determine what module and hook/event it is
for. That's because we use PHP core coding standards, which say to use
function_name for all functions. So given this function name:
views_do_stuff()
Is that the "do stuff" hook from the "views" module/plugin, or the "stuff"
hook from the "views_do" module? Excellent question, and one that cannot be
reliably solved. (There is a module called "views", but nothing is stopping
anyone from writing a "views_do" module and declaring their own "stuff"
hook.)
That has actually come up recently as a problem, where we had to change the
way a feature was implemented in order to avoid that problem of lack of
introspection. (Ironically, it was when we were trying to implement lazy
loading of a larger number of files to *improve* performance by reducing the
amount of parsed-but-unused code we have.) We also are more and more coming
across very_long_function_names since the function name must begin with the
name of the module, which, if multi-word, can get quite long.
When I saw the namespaces implementation, I realized that was a good solution
to the problem. Instead of $module .'_'. $hook, use $module .'::'. $hook.
That doesn't use namespaces as an alias or a shortener, but as, genuinely, a
namespace.
That's what's wrong with Long_Name_Prefixes. Aside from being a bitch to type
or read, they don't contain as much introspective metadata as namespaces do.
A registry on php.net to avoid collisions solves the problem for only one
tiny sliver of use cases.
If the problem with the current namespace implementation is that it doesn't go
far enough, then the answer is not to drop it entirely but to finish it.
Even if it's not useful in every use case, there are a lot of use cases where
it is useful.
To the other items raised:
1) "use MyDate as DateTime". I believe Greg pointed out the solution here.
When PHP 5.5 is released and adds its own Whatever class, you just do the
following:
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
It's a one-line change to keep your code working. I think that's acceptable,
especially if we ensure that Whatever not existing in the global namespace
(on 5.4) doesn't cause an error. As Stanislav noted, a complete solution is
impossible. The Global namespace is a namespace, and you can't add things to
a namespace and expect there to never be a collision within that namespace.
Duh. :-)
2) No "use Foo::* as *". I can certainly see where that would be useful, but
the lack of it does not mean that the entire namespace implementation must be
thrown out. It still offers other benefits, even if it's not perfect (see
above), and I don't see where adding * capabilities in a later version would
cause a BC break syntactically, so worst case it's added later.
3) namespace keyword vs. {}. I've already said before that I prefer the {}
syntax for consistency with other constructs. I am less bothered by the
one-namespace-per-file rule than some, perhaps because I prefer to only parse
the code I need rather than loading everything. (In my common use case,
Drupal, that's a bigger performance win than vice versa.) I do agree that IF
multiple namespaces are allowed in one file, {} makes a lot more syntactic
sense than just a keyword. That said... is the keyword vs. {} issue worth
deep sixing namespaces completely? If so, um, let's switch to {} (with or
without multiple namespaces per file) and solve the problem? :-)
For whatever the opinion of someone who writes PHP all day and not C is worth,
there it is.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
