Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40418
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.48 cause and error)
To: internals@lists.php.net
Date: Tue, 9 Sep 2008 11:25:11 -0500
User-Agent: KMail/1.9.9
References: <ADD0525F-F900-4F3A-9B76-1ED332CA31E0@pooteeweet.org> <48C5668E.7040503@zend.com> <45212116-55A0-4683-8BF7-E3723637158D@pooteeweet.org>
In-Reply-To: <45212116-55A0-4683-8BF7-E3723637158D@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200809091125.11662.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Re: towards a 5.3 release
From: larry@garfieldtech.com (Larry Garfield)

On Monday 08 September 2008 1:45:35 pm Lukas Kahwe Smith wrote:
> On 08.09.2008, at 19:53, Dmitry Stogov wrote:
> > The main PHP namespaces ideas come from Java packages and Java classes
> > have to write these "use" statements in the same way. It's not the end
> > of the world. I believe that well-designed frameworks won't require a
> > lot of use statements in user-space code.
>
> Given the overwhelming feedback that this is indeed a big issue, I
> would be more careful with saying this is a non issue for "well
> designed" frameworks. If someone could post some links to their
> namespace using code that is suffering from the current situation it
> would provide a good opportunity for all of us to review and comment
> (hopefully in a respectful manner .. after all these people are
> treading on new territory so its much easier to make witty comments
> than doing the initial hard work of trying to do something new).
> Especially in this sense I would recommend all people on this list to
> make sure they use language that encourages people from coming out of
> the shadows on this topic, rather than scaring them off.
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

I don't have code for it yet, but perhaps I can describe the way Drupal 
(a "well designed" framework that is about 99% procedural code at the moment) 
would most likely make use of namespaces and those who know what they're 
talking about can say if it will be a problem or not.

Drupal's primary extension mechanism at present is hooks.  Hooks are magically 
named functions, formed from the name of the plugin module that provides them 
and some "hook" name.

Other modules may invoke any hook at any time with the following.  (Not the 
actual code, but enough to demonstrate the idea.)

function module_invoke_all($hook) {
  $args = func_get_args();
  array_shift($args);
  foreach (module_list() as $module) {
    $function = $module . '_' . $hook;
    if (function_exists($function) {
      $return[] = call_user_func_array($function, $args);
    }
  }
  return $return;
}

function modulea_foo() { ... }

function dostuff() {
   $stuff = module_invoke_all('foo');
}

In the latest version we've added a lazy-load mechanism for functions, too, so 
we don't have to load the entire code base.  

We keep having people suggesting that we use a class-per-module instead of 
prefixes.  I usually shoot them down as that is a horrifically stupid idea.  
For one, classes are *not* namespaces.  Using them as one violates the way 
classes are designed to work.  For another, it means all code for a given 
module would have to live in one and only one file.  By using functions, we 
are able to have modules implement hooks on behalf of other modules.  We can 
also split a module into multiple files, so code that is used only very 
rarely needn't be loaded on every page load.

Looking at namespaces, they seem at first glance like a better alternative to 
prefixes.  My natural inclination would be:

core.inc:
<?php
function module_invoke_all($hook) {
  $args = func_get_args();
  array_shift($args);
  foreach (module_list() as $module) {
    $function = $module . '::' . $hook;
    if (function_exists($function) {
      $return[] = call_user_func_array($function, $args);
    }
  }
  return $return;
}
?>

modulea.module:
<?php
namespace modulea;

function foo() { ... }
?>

moduleb.module:
<?php
namespace moduleb;

function dostuff() {
  $stuff = module_invoke_all('foo');
}
?>

So given the current implementation, how badly will this break?  When we 
replace function_exists() with our own implementation that lazy-loads the 
file that contains that function on demand (we already have that), how badly 
will that fail?

How confused will PHP get if we introduce more classes (we are doing so) 
within modules?  The re-use of :: still feels like a landmine to me.  Not to 
reopen fresh wounds, but is there any documentation somewhere on why :: was 
chosen as the symbol for namespaces?  Every time the issue gets raised I 
don't see a justification for :: other than "we've already dealt with that, 
don't start again" and "well why are you using functions in namespaces in the 
first place?"  Is there anywhere (other than 5 year old list archives) we 
could see what the reasoning for :: is other than "that's what C++ does"?  
I'm really not trying to start another debate here; I'm genuinely curious.  

The one-namespace-per-file restriction really does nothing to help us 
(Drupal), but we would be able to work around it.  I guess I still don't get 
why it's so necessary if you just take the time to write an intelligent 
autoloader.  (Drupal's autoload implementation is two and only ever two 
callbacks that get cached, so they are rarely called anyway.)

Anyway, just trying to provide another data point for consideration.

-- 
Larry Garfield
larry@garfieldtech.com