Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56264
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EBC5A86.9050803@gmail.com>
References: <CAAyV7nEi+1XzYryoE9tg48jZMMPe1psz=VWDkGSzEgAwBKs9pw@mail.gmail.com>
	<4EBC5A86.9050803@gmail.com>
Date: Thu, 10 Nov 2011 18:29:24 -0500
Message-ID: <CAAyV7nEGgS9=SGjN4g50_igC76VMgy9ooUy3Wi=W3_ABW1jR6A@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: guilhermeblanco@gmail.com, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=00163642716859399604b169c606
Subject: Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements
From: ircmaxell@gmail.com (Anthony Ferrara)

--00163642716859399604b169c606
Content-Type: text/plain; charset=ISO-8859-1

Well, the problem with adding methods later is that it will fatal any class
that implements the old one.  A big no no.

You could get around that by doing something like traversable.  Provide an
empty and non usable core SplAutoloader interface which is typehintable.
Then add a child SplClassAutoloader interface which defines loadClass.
That way, in the future a new child could be added SplFunctionAutoloader
which defines loadFunction.

By separating them, you maintain type hinting while enabling backwards
compatibility with existing code...

Just a thought.
On Nov 10, 2011 6:13 PM, "David Muir" <davidkmuir@gmail.com> wrote:

> 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
>
>

--00163642716859399604b169c606--