Re: RFC: spl_autoload_register() should provide kind of entity to load

Effectively from this perspective, i get it. I'm not a fan of PSR-4 convention as they are not officialy supported by PHP but i understand your both (Ryan, Anthony) point of view. Also well done for catching the Hungarian notation, i just noticed that is a bad pratice. Anyway, thanks for your (quick) feedback. Regards. Geolim4 2015-04-18 17:09 GMT+02:00 Ryan Pallas <derokorian@gmail.com>: > > > On Sat, Apr 18, 2015 at 8:24 AM, georges <geolim4@gmail.com> wrote: > >> ​Hi php internals, >> >> Currently spl_autoload_register() pass the name of the class entity to the >> first *Callable* argument​, but there is now way (as i far i know) to know >> what kind of entity we're looking for. >> -Class ? >> -Interface ? >> -Trait? >> >> >> A second argument should be added to the *Callable* function describing >> what kind of entity we're looking for. >> >> Example: >> >> <?php >> >> // function __autoload($class) { >> // include 'classes/' . $class . '.class.php'; >> // } >> >> function my_autoloader($entity, $kind = "class") { >> // Kind would be: class/interface/trait >> include $kind . '/' . $entity . ".{$kind}.php"; >> } >> >> spl_autoload_register('my_autoloader'); >> >> // Or, using an anonymous function as of PHP 5.3.0 >> spl_autoload_register(function ($entity, $kind = "class") { >> // Kind would be: class/interface/trait >> include $kind . '/' . $entity . ".{$kind}.php"; >> }); >> >> ?> >> >> >> In fact i think currently that Autoload is too much "class oriented" as >> per >> reading php docs, whereas that php currently allow the autoload of many >> entities. It can really confuse probies php developers :( >> >> *Pros*: >> >> - -Avoid multiple else if() for testing an existing file to load the >> entity. >> - -As we now know the type of entity to load, it help reduce I/O >> activity, then reduce timespend. >> - -Clarify the code: We now what the autoloader will load >> - -Keep the BC safe >> >> >> *Cons*: >> >> - -None >> >> >> >> Regards, >> Georges.L >> > > I'm not sure I agree. Even in your example, the $kind is in the path > twice, which seems redundant. With a good naming system, the namespace > and/or object name will tell you what it is. IE: > > Library\Module\DataInterface maps to > /path/to/project/library/module/DataInterface.php > Library\Module\LogInterface maps to > /path/to/project/library/module/LogInterface.php > > Library\Traits\Singleton maps to > /path/to/project/library/traits/Singleton.php > > Also, check out PSR-0 and PSR-4 (not affiliated with the PHP devs, but > framework owners developing for PHP) which shows how naming conventions > like this can lead to only a single file exists check, further simplifying > the autoloader. > > Maybe its not the best code, but this is how simple my autoloader is with > a naming convention like this (Note: DS = DIRECTORY_SEPARATOR but its too > long): > > spl_autoload_register(function ($strClass) > { > $strFile = $strClass . '.php'; > $strNameSpace = ''; > if ( ($iLast = strripos($strClass, '\\')) !== false ) { > $strNameSpace = DS . str_replace('\\', DS, substr($strClass, 0, > $iLast)); > $strNameSpace = implode('_', > preg_split('/(?<=[a-zA-Z])(?=[A-Z])/s', $strNameSpace)); > $strFile = substr($strClass, $iLast + 1) . '.php'; > } > $strFilePath = ROOT . strtolower($strNameSpace) . DS . $strFile; > if( is_readable($strFilePath) ) { > require_once $strFilePath; > return true; > } > return false; > }); > > As you can see, by the result of the naming convention, I know where the > class/interface/trait will be defined based on its namespace and name. > Since traits live under a traits folder, its obvious from their location on > the filesystem what they are (no need to .trait.php at the end). > Additionally since Interface is how all interfaces end in name, the > filename would be redundant to have .interface.php at the end. > > -Ryan >