Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.44 as permitted sender)
Message-ID: <4EBC5A86.9050803@gmail.com>
Date: Fri, 11 Nov 2011 10:13:10 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: PHP Internals <internals@lists.php.net>, guilhermeblanco@gmail.com
References: <CAAyV7nEi+1XzYryoE9tg48jZMMPe1psz=VWDkGSzEgAwBKs9pw@mail.gmail.com>
In-Reply-To: <CAAyV7nEi+1XzYryoE9tg48jZMMPe1psz=VWDkGSzEgAwBKs9pw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements
From: davidkmuir@gmail.com (David Muir)

Surprised to say that I agree on just about everything you mentioned. I
would however love to see a useful autoloader included in core. I have
only one comment below.
> 4. The RFC should avoid implementing any pattern or style that may
> make future feature addition difficult or pose risks towards such.  An
> example would be implementing an interface for the autoloader which
> defines something like load($class).  The problem there is that if
> function autoloading is added, the interface won't be able to support
> it.  So it's stuck in a hard place between changing an implemented
> interface (which will bork code significantly on update) and adding a
> new interface (which would be the lesser of evils, but would just add
> to the deprecated cruft).

IMO, the interface should just define loadClass($class). It means that
spl_autoload_register has a fixed target for loading classes, and if we
want to support autoloading functions or whatever else later on, a new
interface can be added that would define the appropriate method eg.
loadFunction($function).

Cheers,
David