Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85863
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAObuZdsR1g72bSqsfzqUO_H2BjvZqvb96kcUP9oPgR+Q+E6uqg@mail.gmail.com>
References: <CACjyb+wzguSRSW5qz-bLT1GU4xbQjFk-4VyaQjMasQ+e1xDn=w@mail.gmail.com>
 <CAObuZdsR1g72bSqsfzqUO_H2BjvZqvb96kcUP9oPgR+Q+E6uqg@mail.gmail.com>
Date: Sat, 18 Apr 2015 17:20:28 +0200
Message-ID: <CACjyb+zHX_PHtv5h7HOzWb4roZ-yMZPubn75buxkMOh2OjLkvg@mail.gmail.com>
To: Ryan Pallas <derokorian@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11476fc0774f680514013e52
Subject: Re: [PHP-DEV] RFC: spl_autoload_register() should provide kind of
 entity to load
From: geolim4@gmail.com (georges)

--001a11476fc0774f680514013e52
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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:
>
>> =E2=80=8BHi php internals,
>>
>> Currently spl_autoload_register() pass the name of the class entity to t=
he
>> first *Callable* argument=E2=80=8B, but there is now way (as i far i kno=
w) 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
>> 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 simplifyin=
g
> 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 t=
oo
> 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
>

--001a11476fc0774f680514013e52--