2007/12/10, Stanislav Malyshev <[EMAIL PROTECTED]>:
>
> > All namespace access should be explicit:
>
> Consequence: nobody uses namespaces, as it's too annoying.


Putting $this-> and self:: is annoying , that didn't stop anybody from using
objects in PHP.

> b) Name aliasing with use should only generate namespaces aliases:
>
> See no reason for that limitation. Used in moderation, class aliasing is
> OK. Main thing is not to rely on it for everything.


Maybe, but then I'll suggest that these aliases are accessed through
namespace:: or similar.

> 2) Using :: as namespace separator generates ambiguity
>
> Would that be 20th reincarnation of "let's find weirdest namespace
> separator" thread? :)


Please no. Just find the right one.

> <?php
> > ...
> > Foo::test(); // a member function? a namespaced function?
> > ?>
>
> Sometimes you need context. When you just take $foo->bar() it doesn't
> give you much - you should know what $foo is and what bar() does.


But you still know that $foo->bar is a member function call. That
information only makes code review and debugging a lot easier. The current
implementation of namespaces introduces a lot of uncertainty. I do not need
to tell you how hard and time consuming it is to debug or review C++ code. I
beg you, please do not make PHP a language that's as harder to debug or
review.

And even if you say "sometimes you need context", be prepared to be asked
"why now?".
Why context was not applied inside a class definition?
Why do I have to use $this-> or self::?
Why is there no with ($object) { ... } ?

> Why is this an argument against: there was not a construct that works as
> > this one in PHP.
>
> This is not an argument - each construct works as needed for it to work
> to achieve its purpose.


So, every construct of a language works as a distinct unit?
There's no need to keep cohesiveness with how other constructs behave?
We'll have to accept that now there'll be statements that enforces a scope?
No problem then, I'll start training my brain to remember the namespaces and
imports of each file.

Maybe it makes sense in a language like Java that also enforces a directory
structure, but PHP?

> c) If bracketed namespaces are a no-go, consider the possibility of
> > declaring the full name of the namespaced element in its definition:
>
> Which would lead to people routinely mixing different namespaces inside
> one file. Bad idea. Also would kill namespaced functions and constants,
> which would make organizing libraries using those impossible.


Why would it lead to people routinely mixing different namespaces inside one
file?
Why is this bad in the first place?
Why is it the language the one to decide which is the better way to organize
code?

Also, that would not kill neither namespaced functions nor constants:

<?php
function namespaced::foo() {
...
}
const namespaced::CONST = "I'm namespaced!";
?>

Reply via email to