Hi,
Some questions about namespaces now that PHP 5.3 continues to evolve
- 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.
- Do we really need namespaced constants?
These can conflict with class constants and there is no way to resolve
the difference external to that namespace.
- 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(){}
}
?>
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.
Thanks,
Greg
Hi,
Some questions about namespaces now that PHP 5.3 continues to evolve
- Do we need functions in namespaces now that we have closures?
Functions suffer just as much as classes with respect to naming
collisions. Removal of support for functions in any namespace
implementation would be short-sighted.
Cheers,
Rob.
http://www.interjinn.com
Application and Templating Framework for PHP
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
- 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.
- Do we really need namespaced constants?
Eh, +0.5. :-)
- 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
Hi!
namespace Foo {
}
OMG, not again... How many times should we talk about the same thing?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com