Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39031
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.56 cause and error)
To: internals@lists.php.net
Date: Wed, 16 Jul 2008 22:40:17 -0500
User-Agent: KMail/1.9.9
References: <487EB028.5090201@chiaraquartet.net>
In-Reply-To: <487EB028.5090201@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200807162240.17407.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] questions about namespaces, functions vs. closures
From: larry@garfieldtech.com (Larry Garfield)

On Wednesday 16 July 2008 9:36:24 pm Greg Beaver wrote:
> Hi,
>
> Some questions about namespaces now that PHP 5.3 continues to evolve
>
> 1) Do we need functions in namespaces now that we have closures?
>
> One of the main reasons I wanted functions in namespaces was to
> implement callbacks.  Now that we have closures in PHP 5.3, for me there
> is no longer any good reason to have functions in namespaces other than
> porting legacy code.
>
> Because the only remaining serious naming conflict is between namespaced
> functions and static class methods, I wonder how many people would find
> closures an acceptable substitute for allowing functions in namespaces?
> Also, see #3 as a way to solve the question of porting old code.
>
> My assumption is that namespaces are best as a library helper for
> re-usable classes.

I don't know whether +1 or -1 would mean "keep namespaced functions" here, so 
I will just say "Keep namespaced functions!"

very_long_function_names_for_namespacing is just as much a problem as long 
class names for the same reason.  My primary development system is 99% 
functions, and uses name-based namespacing now.  Real namespaces would be 
quite a boon and solve a dozen or so problems for us, if they work right.

> 2) Do we really need namespaced constants?

Eh, +0.5. :-)

> 3) Now that it has been pointed out that use can't be used in brackets,
> could we consider moving namespace syntax to a syntax proposal Dmitry
> made a while ago:
>
> <?php
> namespace Foo {
> }
> namespace Bar {
> // this shows how to port legacy code - you simply have to explicitly
> use old functions.
> use ::blah();
> }
> namespace {
> function blah(){}
> }
> ?>

I don't recall the full proposal so I cannot comment as the devil is in the 
details.  In general, transitioning from non-namespaced code to namespaced 
code should be as graceful as possible (e.g., avoiding a requirement to 
explicitly name all global functions you're going to use within a given block 
before using them.)

> The last example would be for porting legacy un-namespaced code (for
> instance, utility functions) or global application code that uses the
> previous stuff.
>
> If possible, could answers to these questions be limited to +1/-1?  I
> would like to get a sense of how controversial these ideas are rather
> than to just debate them.  If you absolutely must reply with other
> ideas, then please start a new thread.

Sorry, it wasn't really possible. :-(

-- 
Larry Garfield
larry@garfieldtech.com