Re: Namaspaces, caling functions and classes defined in the global name space
- From: taps128 <nstjelja@xxxxxxxxx>
- Date: Fri, 30 Nov 2007 13:55:23 +0100
Toby A Inkster wrote:
taps128 wrote:
I can't stop thinkign this is to complicated to read. Wouldn't be simple
to just use the GLOBAL keyword for the global namespace, so this:
A::foo() will run the function foo from the A namespace, and this
GLOBAL::A::foo() will run the static mehod foo of class A from the
global namespace.
Firstly, what did I tell you in that "Assigning variables in ifs" thread?!
"GLOBAL::A::foo()" is a waste of 6 bytes! Six precious bytes!
::A::foo() is clear when you consider namespaces to be a bit like Unix paths. "A/foo.txt" means "from the current directory, find subdirectory A, and in there, look at file foo.txt". However, "/A/foo.txt" has an entirely different meaning -- "from the root directory, find subdirectory A and in there, look at file foo.txt".
Consider namespaces, classes and methods to be like a Unix file system, but with :: as a path separator instead of /, and it all becomes clear. The "namespace" keyword then becomes equivalent to "chdir". It takes the mystery out of namespaces by making them work like something you're already familiar with.
That said, it's probably going to be pretty rare when you're going to explicitly want to reference the global namespace.
If you're coding without namespaces, everything's already in the global namespace, so you never need to explicitly reference it.
If you're coding in a namespace and you've defined your own function preg_match(), then chances are, when you call preg_match(), it's your own function that you want to run -- the main exception being that if your preg_match() function is a wrapper around the global preg_match, then your preg_match will need to call the global preg_match, and then you'll need to explicitly reference the global namespace.
Overall, I think they've managed fairly miraculously to introduce namespaces without breaking old code.
Yes but , as I've previously stated, readibilty is king. When you look at
::A::foo();
your don't know what you are looking at exactly. It could be a function foo or a method of static class from the global namespace. When you debug or mantain someone else's code that could be a very big problem, since I generally need to know what something is.
To put a pun on you byte saving ranting it would actually cost me (or someone else ) more bytes doing things this way. Why? That's becuse that line of code requires a comment. So
::A::foo();
becomes:
//ns func
::A::foo();
or
//glob stat method
::A::foo();
I don't know but it seems to me that this way of using namespaces is something that could possibly cause a lot of headaches.
I know that something else could, well, possibly break backwards compatibily, but what the cost. Messy code, nerve breakdowns, early retirements. It could well mean the end of whole economies.
I think a more rigid apporoach should be considered.
.
- Follow-Ups:
- Re: Namaspaces, caling functions and classes defined in the global name space
- From: Toby A Inkster
- Re: Namaspaces, caling functions and classes defined in the global name space
- References:
- Prev by Date: Re: Joomla?
- Next by Date: Re: Joomla?
- Previous by thread: Re: Namaspaces, caling functions and classes defined in the global name space
- Next by thread: Re: Namaspaces, caling functions and classes defined in the global name space
- Index(es):
Relevant Pages
|
