On Tue, 2007-12-04 at 22:26 -0600, Larry Garfield wrote:
> 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.)
<?php
$hook = 'omg';
foreach ($modules_that_are_loaded as $module)
{
$function = $module .'__'. $hook;
if (function_exists($function))
{
$return[] = $function();
}
}
return $return;
?>
There ye have it!
<?php
list( $module, $hook ) = explode( '__', $function );
?>
Namespace support is for people who didn't name their classes/functions
properly. I'm not for or against it.
Cheers,
Rob.
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
