Stas,
On Mon, Sep 2, 2013 at 4:02 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi!
>
> > So the only case this effects is that you can't autoload a function from
> > the same namespace that you're currently in without explicitly using
> > that function.
> >
> > That's not such a huge issue.
>
> I think it is such a huge issue, because this means this functionality
> can not be used for reliably loading namespaced functions without prior
> declaration, and this is pretty much the use case we've been preached
> about all along. So if it doesn't work in this case without prior
> declarations just for it, than how it's better than require?
It doesn't *need* prior declaration. It needs either prior declaration or
qualification (absolute or relative). But more on that in a sec.
> > But "fixing" that would be such a massive BC break...
>
> There's nothing to "fix", it was a conscious decision about how
> namespaces must work. Alternative is doing \strlen each time you need
> string length, which would be just silly.
So what your saying, if I understand you correctly, is that PHP was
intentionally designed to be non-deterministic? And it was designed that
way to save a single character?
To get why I think that's such a big deal, let's look at some sample code:
namespace Foo {
function test1($input) {
return strlen($input);
}
function test2($input) {
return strlen($input);
}
var_dump(test1("test")); // int(4)
// Simulate require
eval('namespace Foo { function strlen($input) { return 42; }}');
var_dump(test2("test")); // int(42)
var_dump(test1("test")); // int(4) on 5.4+, int(42) on 5.3
}
The eval is just there to simulate a require_once. Thanks to function
caching, NOTHING makes sense!!! http://3v4l.org/MMvFv
If you don't agree that behavior is wonky, then I'm not sure where else to
go.
> > You would only need to explicitly `use function` those in your current
> > namespace. Any outside (relative or absolute calls) would still work
> fine.
>
> It's not "only" - functions in current namespace are exactly those I'm
> likely to use.
Look at the code where you use classes. How many times to do use a class
from your current namespace vs another one. The code I've looked at tends
to favor other namespaces significantly...
> > And after all, this is the exact reason we implemented `use function`.
> > Because namespaces WERE useless for functions until last week. Now we
> > have the power to be explicit with our calls.
>
> I don't think RFC proposed well before this issue was raised was
> actually meant only to fix broken function autoloading proposal. I
> sincerely hope it has more uses than that, otherwise it's a pretty big
> mistake.
> > That's how functions (and namespaces) have always worked. Give it a
> > try: http://3v4l.org/S6FN8 Keep in mind, functions have been treated as
>
> No it's not how it worked - function resolution rules were always "try
> namespace, then global", unless alias is explicitly specified by use
> (aliased name is treated as fully qualified, because this is what the
> function of aliasing is). Just try to remove "use" statement and see.
It's only "try namespace, then global" in the case where there's no `\` in
the function name. Compile code that does the check:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_compile.c#1938
> > The big difference is that last time there was no mechanism to be
> > explicit with what you wanted your code to do without fully qualifying
> > every call. Today we have `use function`.
>
> Which is the same specification, just at the beginning of the file. I'd
> rather do one require then ten use functions. My opinion is producing
> autoloader that is inconsistent with how language itself treats import
> would only produce more WTFs and more people thinking nothing in PHP
> makes sense and nobody cares about internal consistency of the language.
>
Anthony
PS: I think it's ironic talking about internal consistency of a language in
the same reply where you justify "try namespace, then global" as a good
design feature. Just pointing that out...
