Importing namespaced functions View as Markdown

+1

The current behavior is really annoying.

2013/4/22 Florian Anderiasch ml@anderiasch.de

I agree with Igor. The readability could be improved and I do not see the
problem of hiding built-in php functions (however, I would not recommend
it).
I would say, if someone hides the normal php built-in function then he or
she is doing that on purpose and is aware of the consequences. Thus it is
also fine if the same person imports the function, which hides the normal
php built-in function, in another namespace.

Huge +1 from me.

I know that using only functions instead of OOP in PHP has this
90s-PHP3-Vibe to it, but as a matter of fact you can write mostly
side-effect free code using only functions in PHP.

This would make using functions much more flexible and even more
importantly, consistent to everything else.

The only downside to this proposal, as Stas correctly mentioned is that
it would allow people to shoot themselves in the foot when using weird
import behavior. But as you deliberately have to misuse this I don't see
any real harm. Something like instance variable shadowing in Java is
much, much more error-prone and still hardly anyone complains about this
kind of feature.

Greetings,
Florian

Hi,

Although this change may cause confusion, but it would be beneficial to
many users as a security counter measure.

For instance, there is CVE-2013-2065 for Ruby

http://www.ruby-lang.org/en/news/2013/05/14/taint-bypass-dl-fiddle-cve-2013-2065/

I suppose this change allow us "monkey patch" PHP without upgrade if it is
needed.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2013/5/3 Igor Wiedler igor@wiedler.ch

Your solution is flawed, it would not allow autoloading a function that
has the same
(namespaced) name as a builtin.

Example:

// autoloadable function
namespace foo {
    // make arg order consistent
    function array_filter($callback, $input) {
        return \array_filter($input, $callback);
    }
    function is_positive($x) {
        return $x > 0;
    }
}

namespace foo {
    var_dump(array_filter('foo\is_positive', [-2, -1, 0, 1, 2]));
}

Always triggering the autoloader is not feasible either, as it will lead
to tons of stat calls,
one per namespace that any global function is called in.

Potential solutions: Only autoload fully qualified or imported functions.

But there is lots of potential for bikeshedding there, plus it requires
more implementation
effort, and quite possibly more performance and cache related
considerations that I am
not aware of.

As much as I would like to see function autoloading, I don't think
bundling the proposals
is going to be beneficial. Which is why I'd rather just focus on one issue
at a time.

Regards,

Igor

Well, it is not as complex as it sounds

This is the behaviour right now

• Does X exists as namespaced function (current namespace or imported)?
• Does X exists as global (builtin) function?
• Trigger error

The behaviour including autoloading would be more like

• Does X exists as namespaced function (current namespace or imported)?
• Does X exists as global (builtin) function?
• Trigger autoload
• Does X exists as namespaced function (current namespace or imported)
  now?
• Maybe: Does X exists as global function now?
• Trigger error

The autoloading itself could use parts already used for
class-autoloading.

// Signature
// spl_autoload_register($callback[, $type = AUTOLOAD_CLASS]);

$autoload = function ($name, $type = AUTOLOAD_CLASS) {
  // Do something
};
spl_autoload_register($autoload, AUTOLOAD_CLASS | AUTOLOAD_FUNCTION

| AUTOLOAD_CONSTANT); // "constant" here just to make it complete

Namespaced functions without autoloading seems kindof incomplete,
especially because it isn't such a big deal to simply use the prefixed one,
so the benefit seems quite small to me :X

use MyFoo\Bar\MathFunctions as math;
$x = math\sin($y);

Just saying :)

Regards,
Sebastian

On May 2, 2013, at 11:40 PM, Sebastian Krebs krebs.seb@gmail.com
wrote:

Hi,

Are you going to cover autoloading of functions too?

Regards,
Sebastian

--
github.com/KingCrunch