On Dec 4, 2007 10:36 PM, Robert Cummings <[EMAIL PROTECTED]> wrote:
>
> 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.
To paint namespaces with such a broad brush isn't terribly fair. I
see other languages such as Java/Perl/C++ using packages/namespace foo
in much the same way I see some people wanting to use it here. As a
way to shorten really long class names while reducing conflicts.
This isn't a new feature to programming in general. The problem I see
going on here is the desire by some to make it do everything _and_
wash the dishes. While noble and probably well intentioned, does
feature X really serve the greater good? It can't solve every problem
and still be something that people want to use.
Php already has a ton of stuff in the global namespace, so I don't
know that namespaces can fix collisions/BC overnight. Once namespaces
have a foothold then people can start looking at how to migrate all
the stuff in the global namespace outwards without causing major
problems. While PHP::Time::DateSpan might seem silly to some, it
seems fairly normal in the other languages I program in (Java, Perl).
I would also be perfectly fine with php core laying claim to Time::*.
Its just a fact of life that the global namespace has a limited amout
of real estate and people can't just go snatching up all the good
names just because they were there first.
I vote for starting small. Add namespaces. Allow people to do basic
use statements. I would even be in favor of multiple namespaces per
file, but would prefer if they were wrapped in {} (it seems more
consistent and easier to mentally parse) otherwise I don't care. From
reading emails today I hope this might be some sort of middle ground
that might prevent completely tossing out this feature.
Having said all of that, you can't stop bad programmers from doing at
least something wrong. Especially not in a language like PHP where
you are given so much freedom to do what you want.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does
it really go down?
<esc>:wq<CR>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
