Hi guys,
I am removing my vote due to a particularly annoying aspect of this
whole RFC/voting structure: the RFC is still in flux!
How on earth are we supposed to be able to vote yay/nay on something
if that something keeps changing, or is very poorly defined? I request
that the RFC itself be discussed further, decisions made on what is
actually to be proposed (the idea of an SplClassLoader in
core/pecl/github/magicyfairyland, or a specific implementation against
SPL, or some interface(s), or some PHP implementation [why is that
even in the RFC?], or ...?), writing the outcome of those decisions
down, then formulating a vote (or selection of votes) only after all
of that.
If the RFC is already considered finalised, please stop changing it.
If the vote is intended as a yes/no to something that's still under
discussion or subject to change, clearly state that in the RFC/vote
page. If the RFC is not finished and voting on it makes little sense,
please remove the poll.
Frustratingly,
Peter
On 9 November 2011 10:24, Christian Kaps <christian.k...@mohiva.com> wrote:
> Hi,
>
> I'm fine with the most of the implementation. But I have some suggestions to
> optimize it.
>
> 1. The interface should be named SplClassLoader and the register and
> unregister methods should be removed.
>
> It should be possible to define class loader implementations without
> registering them as autoloader because autoloading isn't the only way to
> load classes. A class loader could as example return the ReflectionClass
> instance for the loaded class. I think the current interface is to
> restrictive in this case. As compromise it would be possible to define a
> SplClassAutoloader interface too. This interface extends the SplClassLoader
> interface and defines the methods register and unregister.
>
> interface SplClassAutoloader extends SplClassLoader {
>
> public function register($prepend = false);
>
> public function unregister();
> }
>
> As a side note, the two interfaces doesn't violate the Single responsibility
> principle.
>
> I know the reference implementation is named as SplClassLoader but this
> should be renamed into SplDefaultAutoloader or SplPsrAutoloader if
> implements the SplClassAutoloader or as SplPsrClassloader or
> SplDefaultClassloader if implements the SplClassLoader interface.
>
> 2. The function spl_autoload_register() should accept all SplClassLoader
> implementations.
>
> I know it's already possible with the following syntax:
>
> $classLoader = new MyCustomClassLoader();
> spl_autoload_register(array($classLoader, 'load'));
>
> But the following syntax seems more consistent to me:
>
> $classLoader = new MyCustomClassLoader();
> spl_autoload_register($classLoader);
>
> Christian
>
> Am 09.11.2011 02:23, schrieb guilhermebla...@gmail.com:
>>
>> For all those interested, I implemented what I referred as item 2:
>>
>> <quote>
>> After some thought it makes sense, but only if interface then defines
>> the setMode prototype.
>> The background for this is supported if the user decides to enhance
>> the base class to support caching, requiring the injection of the
>> Cache layer in constructor. If it's part of the interface, it cannot
>> be changed.
>> </quote>
>>
>> RFC is now updated covering this. If you have more questions or
>> suggestions, feel free to tell me.
>>
>> On Tue, Nov 8, 2011 at 3:55 PM, guilhermebla...@gmail.com
>> <guilhermebla...@gmail.com> wrote:
>>>
>>> Hi Nikita,
>>>
>>> Thanks.
>>> It's your option and I won't fight. But it seems my proposal is not yet
>>> 100%.
>>> Some things I have either identified or people have reported.
>>>
>>> 1- Remove ->register() and ->unregister(), and make the
>>> spl_autoload_register to support SplClassLoader.
>>>
>>> I'm really +0 on this one.
>>> But since the proposal covers an OO approach for autoload, it makes
>>> sense the registering is pat of the available API, not in procedural
>>> land.
>>>
>>> 2- Remove constructor prototype in interface
>>>
>>> After some thought it makes sense, but only if interface then defines
>>> the setMode prototype.
>>> The background for this is supported if the user decides to enhance
>>> the base class to support caching, requiring the injection of the
>>> Cache layer in constructor. If it's part of the interface, it cannot
>>> be changed.
>>> I took this example after looking at Symfony's
>>> ApcUniversalClassLoader:
>>>
>>>
>>> https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php
>>>
>>>
>>> What do you think about these 2 points?
>>>
>>> Even if you're against the proposal, for sure you can still help to
>>> make it consistent.
>>>
>>>
>>> Cheers,
>>>
>>> On Tue, Nov 8, 2011 at 3:39 PM, Nikita Popov <nikita....@googlemail.com>
>>> wrote:
>>>>
>>>> On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@gmail.com
>>>> <guilhermebla...@gmail.com> wrote:
>>>>>
>>>>> Because there's no need to bring to C a single foreach.
>>>>> Also, if you re-read the RFC, you'll see that SplClassLoader is
>>>>> extendable for personalized developer needs, such as an addAll or an
>>>>> APC lookup.
>>>>
>>>> After your changes the RFC looks much more decent. I am still opposed
>>>> to the idea of this going into core (mainly because there is no
>>>> necessity), but now the implementation is somewhat more useful.
>>>>
>>>> Nikita
>>>>
>>>
>>>
>>>
>>> --
>>> Guilherme Blanco
>>> Mobile: +55 (11) 8118-4422
>>> MSN: guilhermebla...@hotmail.com
>>> São Paulo - SP/Brazil
>>>
>>
>>
>>
>> --
>> Guilherme Blanco
>> Mobile: +55 (11) 8118-4422
>> MSN: guilhermebla...@hotmail.com
>> São Paulo - SP/Brazil
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
