Namaspaces, caling functions and classes defined in the global namespace

I've been reading the namespace specification for the 5.3 relaese, and I
can't stop thinking that they have complicated the thing unecessary.
Here is what I mean.

So far if you call a function or a class in (which is not global )
using this:

::A::foo();

it will first try to run the function foo() from the namespace A , and
if it can't find it it will run the static method of the class A from th
e global namespace.

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.

Re: Namaspaces, caling functions and classes defined in the globalname space

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.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 17:31.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

Re: Namaspaces, caling functions and classes defined in the globalname space

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.

Re: Namaspaces, caling functions and classes defined in the globalname space

taps128 wrote:

> 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.

But prefixing it with GLOBAL doesn't help matters.

GLOBAL::A::foo();

Could be a function foo() in namespace GLOBAL::A or a class method
A::foo() in namespace GLOBAL.

And frankly, if you're "standing outside" A, it doesn't usually make any
difference whether it's a namespace or a class. Class methods can be
called just the same.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 21:41.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/