Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPg3XxLcNHBkFWWrrMmnpoxjFmgyU6pEz4nsq3=5kOHjLCU8tg@mail.gmail.com>
References: <BANLkTi=-qjC22BZOQ8X6YWnJZRiCNdxxhg@mail.gmail.com>
	<BANLkTi=zK6TgvEAT7mhpX60pZp5QaOUGWzTmpXFti8NOGj2ASQ@mail.gmail.com>
	<BANLkTi=pE2qnAwBmY=6gdtc3diXyYEn5-Q@mail.gmail.com>
	<BANLkTimJKwL6YyWg1a3ZAJnJ5ZyNkxMVrg@mail.gmail.com>
	<BANLkTimDs=s8FpTC9oTbvvpYD4mE7d+VuQ@mail.gmail.com>
	<BANLkTi=K_Ga6FjszMdHSGrsCx94XzSC+mg@mail.gmail.com>
	<4E208FE7.4020606@sugarcrm.com>
	<CAFp73Xv_ns2j7d0Na1pQ6xkoqjxSm6bAsZYdFbTUmgghkF8VAg@mail.gmail.com>
	<CAKxcST-=PvFdtzqOHqiTHM7oREHKqXtpzY1P5TwN8Jiwr4tscA@mail.gmail.com>
	<CALa-LwYiOXF8S7rJs6fjpkT8vECjLcsxeu2tE9cNv--DG5pwiw@mail.gmail.com>
	<CAPg3XxLcNHBkFWWrrMmnpoxjFmgyU6pEz4nsq3=5kOHjLCU8tg@mail.gmail.com>
Date: Mon, 24 Oct 2011 11:52:44 -0500
Message-ID: <CALrkBjb=iUMLgxdQKjqps8sskqS5wfVJ2R68ku21X_vkcA1aWw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf307d031075e1e204b00e4017
Subject: Re: [PHP-DEV] SplClassLoader
From: pencap@gmail.com (Mike Willbanks)

--20cf307d031075e1e204b00e4017
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 24, 2011 at 10:20 AM, Peter Cowburn <petercowburn@gmail.com>wrote:

> On 24 October 2011 15:57, David Coallier <davidc@php.net> wrote:
> > On 24 October 2011 16:53, Paul Dragoonis <dragoonis@gmail.com> wrote:
> >> On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com
> >> <guilhermeblanco@gmail.com> wrote:
> >>> Hi internals,
> >>>
> >>> It's been a while since Stas accepted that, but it seems the class
> >>> haven't been merged since then.
> >>> What's the status of this? Can I expect SplClassLoader in 5.4.0?
> >>>
> >>> It seems it was approved, but wasn't merged and thread was lost in
> space. =(
> >>>
> >>> There's an RFC for it: https://wiki.php.net/rfc/splclassloader
> >>> There's a patch for it: https://github.com/metagoto/splclassloader
> >
> > If we can identify where we want it in the structure of the PHP
> > project, I'll be happy to merge the implementation and modify the
> > config files to have --enable-spl-autoloader or such.
>
> Forgive me for not reading the code (yet) but what need is there for
> an --enable-spl-autoloader flag?
>

I agree; I do not believe that there is a need for an enable flag in this
case.  It should just be there or not at all.


>
> What are peoples' thoughts on the name of the class? The word "auto"
> fits best with all that has come before, yet the proposal here uses
> "class": what about SplAutoloader?  With the introduction of this new
> class, whatever the name, what happens to __autoload() and
> spl_autoload_register(), if anything? How many ways do we want/need to
> load a class?


I believe by calling a class SplAutoloader when there is already an
implementation of spl_autoload that does something very different it would
be advised to not name it of the same sort... this is what people would
start to think about.  The name SplClassLoader is much more specific.  If we
needed to keep the word "Auto" it would seem better named
SplClassAutoLoader.

spl_autoload is completely separate from __autoload today.  Also __autoload
does differ from the spl_autoload facility in several ways and is not
recommended even from the manual standpoint: www.php.net/autoload.
 Secondarily; a class loader cannot autoload functions - it is made to only
implement PSR-0 and nothing more.  While you may use spl_autoload to load
classes the implementation can also load in functions.  This class is really
just enforcing a specific standardization.

--20cf307d031075e1e204b00e4017--