global function and PSR-0?

[Leeoniya]

Hi peeps,

I was wondering if there was a defined way to introduce a global function while still adhering to PSR-0 autoloading standard? I need to define a single global function which will be available to every script without needing a manual 'include' or 'require'.

Since PSR-0 requires a vendor namespace, I'm not seeing how this can be done. I dont want users to have to type use LongVendorName\funcname; funcname($my_var); or LongVendorName\funcname($my_var);.

thanks,
-leon

[Fou-Lu]

I don't believe that there is no, but I can't verify for 100% certainty since I use namespaces exclusively with objects and constants (and actually, I can't recall the last time I made just a function tbh). A big part of the purpose of namespaces being used is to prevent the potential collisions that occur by segmenting each "part" into its own little sandbox; it also allows the closest thing we'll get to overloading in PHP (ie: I can do:

PHP Code:

namespace MyNamespace
{
    function strlen($s)
    {
        return strlen($s) * 2; // note there is a backslash here; the forums strip them out.  Quote it to see.
    }
} 


), so it will create ambiguity if I don't specify which function's I'm looking for. It will always fallback on a global though, so if I try strlen() within namespace MyNamespace2, then it will attempt to load MyNamespace2\strlen and if it cannot find it will revert to \strlen. So even global classes for example require importing into a custom namespace; global fallback only works on functions and constants.

You can of course use an auto_prepend_file directive in order to automatically load a specific script prior to any other processing. Perhaps this could be of use in organizing a global script which imports the necessary namespace functions via aliasing (I think you can import function's as alias)? Ultimately it will come down to if you can do use MyNamespace\functionName AS thatFunction;, for which I'm afraid I just don't know offhand and the documentation doesn't appear to specify this for functions. Maybe you could get away with the prepended file and a closure approach, I'll give these couple a try when I get home.

Another question could be, why? Since you are referring to vendor here, that would indicate to me that code blocks are created by many third party. With this assumption, I would suppose that a common api is provided, and I'm guessing there is class use involved as well? If so, you can simply force them to extend an abstract class which allows the gateway between their functional code and your expectations. This abstract could be used to enforce a namespace import as well.

[Leeoniya]

requiring anyone to configure auto_prepend_file sounds truly terrifying, so that's off the table.

for context, i've basically rewritten my own lib https://github.com/leeoniya/dump_r.php because as I add features it's becoming complex enough to warrant a re-architechture/modularization. the way it's used now is

PHP Code:

<?php
require 'dump_r.php';

dump_r($blah);

since the purpose of the lib is to replace var_dump() and print_r(), an auto-loaded global would be ideal. it can do a function_exists() check to avoid collisions. with PSR-0 things get more complicated but maybe less-so when using Composer/Packagist. currently the lib doesn't use PSR-0 autoloading, so the composer.json simply has a require files option set. https://github.com/leeoniya/dump_r.p.../composer.json

hopefully i can retain the "files" and simply add "psr-0". http://getcomposer.org/doc/04-schema.md#autoload

outside of Composer, i'll have to include a conditional autoloader. https://gist.github.com/221634

[Fou-Lu]

Firstly, I can verify that you cannot import and alias a function name. So if you were to namespace a function you must call it as a fully qualified namespace. So for that I'd recommend a static method in a class so at least you can import the class and target the class without a fully qualified namespace.

If your dump_r isn't namespaced, then simply import it into scope or the global runner. Ultimately, you have a common inclusion point somewhere. Using the use keyword doesn't create anything special, it simply checks the symbols table for a valid class/function/constant under that name, and if it cannot find it it will attempt to load it if you've registered the spl_autoload for the class and the path matches (or used a custom autoload function). If it isn't loaded into symbols and it doesn't have an autoloader for it, then it will fail to load. So somewhere everything is either including something specific, or is being used in a composed environment that already has this information available (ie the runner).
This is where you can import your common code.