Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ez.no from 209.85.210.44 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFp73Xv-Fz=4XUgL4pwVHYb4i9qkB=wNYXqw=xTarBm=_AH9bg@mail.gmail.com>
References: <CALa-LwbbENc-ZQ=+5SJdA0P3Oa5mH6sJmvhYTm30J2p+9Sg5zg@mail.gmail.com>
 <4EB81703.7030605@hoa-project.net> <CAFp73XtYWwQOVnHKdNtNhkNNg2EhoQN1S8ZDnJnQpMC1E31xXA@mail.gmail.com>
 <4EB81C84.8010609@hoa-project.net> <CAFp73Xveea1e=atv4DTKqmcRG2H4Su1gvV70a1uxLJ4pR=GU6w@mail.gmail.com>
 <4EB820BB.2030009@lsces.co.uk> <4EB822D4.4060306@hoa-project.net>
 <CAH-PCH6JUB7a+JZmbbmMs9Fzj_4WvLtnJ=mKgbt-9gwzLj-O9Q@mail.gmail.com>
 <4EB89C36.5000503@garfieldtech.com> <4EB8A22B.8000607@lerdorf.com>
 <CAFp73XsmekJQddrxxyehMQkuZ6FWXb5_9pccVruZ7mNgHh2Xvw@mail.gmail.com>
 <CAF+90c_PXBNXXemz6R2y2NUtKm0Nn37=vy5cvzqzQ5+jirKitw@mail.gmail.com>
 <CAFp73Xvn2svxwSN79xQ6UEw=YZaegC5ekenSPPoYaw7=bQVXLg@mail.gmail.com>
 <CAF+90c-3EJd_9K9jvmsUCze_karW-tnwK01RL4GUzYRNMCvNkQ@mail.gmail.com> <CAFp73Xv-Fz=4XUgL4pwVHYb4i9qkB=wNYXqw=xTarBm=_AH9bg@mail.gmail.com>
Date: Wed, 9 Nov 2011 21:35:24 +0100
Message-ID: <CAGMw7vF1GJiY+auO4whpec_td7faxiceecn26=RirN8DUE-jQw@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=bcaec5215f737bf5cb04b1533b07
Subject: Re: [PHP-DEV] SplClassLoader RFC Voting phase
From: ar@ez.no (=?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?=)

--bcaec5215f737bf5cb04b1533b07
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 8, 2011 at 6:55 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> Hi Nikita,
>
> Thanks.
> It's your option and I won't fight. But it seems my proposal is not yet
> 100%.
> Some things I have either identified or people have reported.
>
> 1- Remove ->register() and ->unregister(), and make the
> spl_autoload_register to support SplClassLoader.
>
> I'm really +0 on this one.
> But since the proposal covers an OO approach for autoload, it makes
> sense the registering is pat of the available API, not in procedural
> land.
>


+1 on remove, don't duplicate things already part of php.


While on duplication, why complicate things by having custom
$includePathLookup support?
This is already handled by php isn't it?


>
> 2- Remove constructor prototype in interface
>
> After some thought it makes sense, but only if interface then defines
> the setMode prototype.
> The background for this is supported if the user decides to enhance
> the base class to support caching, requiring the injection of the
> Cache layer in constructor. If it's part of the interface, it cannot
> be changed.
> I took this example after looking at Symfony's
> ApcUniversalClassLoader:
>
> https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php
>
>

+1 on removing constructor from interface.
But imo SplClassLoader should have a constructor where you can optionally
provide a hash of namespace and path, so you can do:

spl_autoload_register( new SplClassLoader( array(
        'ns' => 'path/',
        'ns2' => 'path2/'
) ) );

(assuming spl_autoload_register gets native support for SplAutoloader,
otherwise it it will of course have to be provided as a callback)

--bcaec5215f737bf5cb04b1533b07--