David,
Don't know if you read my post from last night, but I played around with
functions in namespaces and they worked (the change was pretty easy). Though
all this allowed was the following:
<?php
namespace test_ns
{
function test_func
{
echo "hello!\n";
}
}
test_func(); // generates an error, 'test_func' does not exist
test_ns:test_func(); // prints "hello!"
?>
So, for your string example, all this would buy is that you'd call
str:replace instead of str_replace (you can use a colon, basically).
As I mentioned in the post, imports do not fit very well for functions, as
the current namespace import logic is handed off to __autoload, and there is
no such thing for functions. Based on the replies, it seems that most would
agree with only allowing classes inside namespaces.
Either way, I was thinking this morning of a simplified syntax to achieve
the "import class/function foo from bar" behavior:
import test_ns:test_class [as other_class_name]; // class import
import test_ns:test_func() [as other_func_name]; // function import
import test_ns:$test_var [as $other_var_name]; // variable imports?? (if
supported)
I personally would just stay with classes. As it is now, if you need a
function that can be used inside a namespace, you can just add a "globals"
class and add a static method there. If you need a namespace-global
variable, you can also just declare a "globals" class and add a public
member variable to it. So only allowing classes inside namespaces is not a
real limitation to begin with.
Regards,
Jessie
"David Zülke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> +1 to all of these.
>
> I have a #9 to share, too:
> Assuming that PHP 6.0 will also have namespaces support (which would be
> cool), it might make sense to move all internal functions to use
namespaces
> (if they support functions sitting in there - doesn't seem like Jessie's
> current patch will, but then, maybe there's a chance). That way, we could
> clean up naming inconsistencies (think of all the str* functions), and
maybe
> even some of the common annoyances when it comes to parameter order
> (haystack, needle vs. needle, haystack)
>
> Just a thought.
>
> - David
>
>
> > -----Original Message-----
> > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 12, 2005 7:48 PM
> > To: internals
> > Subject: [PHP-DEV] PHP 6.0 Wishlist
> >
> > Since we are breaking a lot of stuff in 6.0, at least with
> > Unicode_semantics=On I am wondering if it may not be time to break some
> > more stuff and do a bit of spring cleaning. It would mean many apps
> > would need some work to work on PHP 6, but at the same time I think it
> > is work people would welcome since it would mostly involve removing
> > hacks instead of adding them. And yes, I know this is pretty
> > controversial, so take a few deep breaths before replying, please.
> >
> > 1. Remove register_globals completely
> >
> > 2. Remove magic_quotes_*
> >
> > 3. Add input filter extension which will include a mechanism for
> > application developers to very easily turn it off which would swap
> > the raw GPC arrays back in case the site had it turned on by default.
> >
> > 4. Include an opcode cache by default. A lot of work has gone into
> > pecl/apc recently, but I am not hung up on which one goes in.
> >
> > 5. Remove safe_mode and focus on open_basedir
> >
> > 6. Remove some stuff that has been marked deprecated since PHP 3/4
> >
> > A couple of others that we could consider, but I don't actually think
> > wins us much apart from academic purity (which I have never been all
> > that keen on) are:
> >
> > 7. Make identifiers case-sensitive
> >
> > 8. Remove various function aliases
> >
> > -Rasmus
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
