Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56266
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: <CAAyV7nEGgS9=SGjN4g50_igC76VMgy9ooUy3Wi=W3_ABW1jR6A@mail.gmail.com>
References: <CAAyV7nEi+1XzYryoE9tg48jZMMPe1psz=VWDkGSzEgAwBKs9pw@mail.gmail.com>
	<4EBC5A86.9050803@gmail.com>
	<CAAyV7nEGgS9=SGjN4g50_igC76VMgy9ooUy3Wi=W3_ABW1jR6A@mail.gmail.com>
Date: Thu, 10 Nov 2011 19:40:40 -0500
Message-ID: <CAAyV7nGVSX7WL1zMEJHYmptf6a5DSFdJK1p0E_T0cBCspH-z8g@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, guilhermeblanco@gmail.com
Content-Type: multipart/alternative; boundary=0016e652f42e457a8404b16ac5bc
Subject: Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements
From: ircmaxell@gmail.com (Anthony Ferrara)

--0016e652f42e457a8404b16ac5bc
Content-Type: text/plain; charset=ISO-8859-1

David

Sorry, I just RE read your reply.  that's basically what you said,  so in
essence I agree...

Anthony
On Nov 10, 2011 6:29 PM, "Anthony Ferrara" <ircmaxell@gmail.com> wrote:

> 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
>>
>>

--0016e652f42e457a8404b16ac5bc--