Le lundi 29 septembre 2008 à 13:48 -0500, Larry Garfield a écrit :
> On Mon, 29 Sep 2008 19:30:00 +0300, "Vesselin Kenashkov" <[EMAIL PROTECTED]>
> wrote:
>
> > My proposal is (if possible/reasonable/performance wise of course) to have
> > a
> > fatal error thrown when during the parse time the engine discovers
> > duplicates like the one described above. What is the point to name in the
> > same way a class and a static method and a namespace and a function in the
> > same way? In my (very humble) opinion this is the best solution, because
> > we
> > keep the :: operator that we are familiar with, the ambiguity is resolved
> > (just not allowing it) and (I guess) the php 5.3 will not be delayed much.
>
> There's nothing "familiar" about :: to 99.99% of PHP developers who haven't
> already been playing with the alphas.
You are forgetting C++ (PHP's oop implementation looks a lot like C++'s
one, and my guess is it was made this way).
Around 40% of the PHP developpers in our team have C++ experience, and
would love to see namespaces in PHP. They don't really care about what
separator is used, but "::" is what they already use in C++
You could say C++ is cheating because you *need* to have everything
defined in header files (eg, no autoload) and the lookup is done at
compile time (eg. we can take time to lookup exactly what we are
invoking), so using different operators isn't needed.
Also, unlike "." (eg, echo foo.bar will echo "foobar" because of php's
permissive/compatible behaviour), "::" isn't allowed for use anywhere
(unexpected T_PAAMAYIM_NEKUDOTAYIM) and is more suited for namespaces
separations (will not break previously badly-written code).
The current implementation in PHP 5.3.0 is nice, I used it for a few
months (had to adapt my code, like replacing "import" by "use"), and I
must say it's working, however if we are to change the "namespace
separator" by something else, it should have been done 3~4 months ago.
Doing it now may cause problem that we didn't think of in one or two
months, so either PHP 5.3.0 should be delayed and the separator changed,
either it's too late to change that.
Anyway I'd be in favor of the "namespace resolution operator" stuff like
":>" (also because it looks like it's smiling ;p )
some::long::namespace:>someclass::function();
We see that we have some::long::namespace, and within this namespace we
call function(), which is a method of someclass.
Changing the operator within the namespace is not something wanted, the
goal is to improve calls lookups, and remove ambiguity to avoid cases
like:
namespace foo;
class bar {
function baz() {}
}
namespace foo::bar;
function baz() {}
In this case you have two different functions :
foo:>bar::baz();
foo::bar:>baz();
In each call, you immediatly see the difference between the namespace
part and the function/class part.
The only part in the implementation which will become a bit more complex
is to resolve a call from a namespace. Eg:
namespace foo;
bar:>baz();
bar::baz();
In the first case we need to prefix "foo::" and in the second one we
need to prefix "foo:>".
The good thing is since there's no reason to reference a namespace by
itself, there shouldn't be any problem to "guess" which separator should
be used.
Mark
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
