Re: SplClassLoader
| From: | Peter Cowburn | Date: | Mon, 24 Oct 2011 15:20:41 +0000 |
| Subject: | Re: SplClassLoader | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-55925@lists.php.net to get a copy of this message | ||
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?
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?
>
> Does anyone have a preference for this?
>
> /ext/spl/
> /ext/spl-loader/
> /ext/spl-autoloader/
>
IMO, new SPL functionality should live in ext/spl, we don't want to
spread the "standard library" too far and wide.
>
>
> --
> David Coallier
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>