Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACjyb+wzguSRSW5qz-bLT1GU4xbQjFk-4VyaQjMasQ+e1xDn=w@mail.gmail.com>
References: <CACjyb+wzguSRSW5qz-bLT1GU4xbQjFk-4VyaQjMasQ+e1xDn=w@mail.gmail.com>
Date: Sat, 18 Apr 2015 09:09:36 -0600
Message-ID: <CAObuZdsR1g72bSqsfzqUO_H2BjvZqvb96kcUP9oPgR+Q+E6uqg@mail.gmail.com>
To: georges <geolim4@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c24118c95d660514011517
Subject: Re: [PHP-DEV] RFC: spl_autoload_register() should provide kind of
 entity to load
From: derokorian@gmail.com (Ryan Pallas)

--001a11c24118c95d660514011517
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 18, 2015 at 8:24 AM, georges <geolim4@gmail.com> wrote:

> =E2=80=8BHi php internals,
>
> Currently spl_autoload_register() pass the name of the class entity to th=
e
> first *Callable* argument=E2=80=8B, 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 =3D "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 =3D "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 p=
er
> 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 =3D DIRECTORY_SEPARATOR but its too
long):

spl_autoload_register(function ($strClass)
{
    $strFile =3D $strClass . '.php';
    $strNameSpace =3D '';
    if ( ($iLast =3D strripos($strClass, '\\')) !=3D=3D false ) {
        $strNameSpace =3D DS . str_replace('\\', DS, substr($strClass, 0,
$iLast));
        $strNameSpace =3D implode('_',
preg_split('/(?<=3D[a-zA-Z])(?=3D[A-Z])/s', $strNameSpace));
        $strFile =3D substr($strClass, $iLast + 1) . '.php';
    }
    $strFilePath =3D 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

--001a11c24118c95d660514011517--