Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56173
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-3EJd_9K9jvmsUCze_karW-tnwK01RL4GUzYRNMCvNkQ@mail.gmail.com>
References: <CALa-LwbbENc-ZQ=+5SJdA0P3Oa5mH6sJmvhYTm30J2p+9Sg5zg@mail.gmail.com>
 <4EB81703.7030605@hoa-project.net> <CAFp73XtYWwQOVnHKdNtNhkNNg2EhoQN1S8ZDnJnQpMC1E31xXA@mail.gmail.com>
 <4EB81C84.8010609@hoa-project.net> <CAFp73Xveea1e=atv4DTKqmcRG2H4Su1gvV70a1uxLJ4pR=GU6w@mail.gmail.com>
 <4EB820BB.2030009@lsces.co.uk> <4EB822D4.4060306@hoa-project.net>
 <CAH-PCH6JUB7a+JZmbbmMs9Fzj_4WvLtnJ=mKgbt-9gwzLj-O9Q@mail.gmail.com>
 <4EB89C36.5000503@garfieldtech.com> <4EB8A22B.8000607@lerdorf.com>
 <CAFp73XsmekJQddrxxyehMQkuZ6FWXb5_9pccVruZ7mNgHh2Xvw@mail.gmail.com>
 <CAF+90c_PXBNXXemz6R2y2NUtKm0Nn37=vy5cvzqzQ5+jirKitw@mail.gmail.com>
 <CAFp73Xvn2svxwSN79xQ6UEw=YZaegC5ekenSPPoYaw7=bQVXLg@mail.gmail.com> <CAF+90c-3EJd_9K9jvmsUCze_karW-tnwK01RL4GUzYRNMCvNkQ@mail.gmail.com>
Date: Tue, 8 Nov 2011 15:55:26 -0200
Message-ID: <CAFp73Xv-Fz=4XUgL4pwVHYb4i9qkB=wNYXqw=xTarBm=_AH9bg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@googlemail.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] SplClassLoader RFC Voting phase
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

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/ClassL=
oader/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.ppv@googlemail.com> wr=
ote:
> On Tue, Nov 8, 2011 at 6:28 PM, guilhermeblanco@gmail.com
> <guilhermeblanco@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
>



--=20
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
S=C3=A3o Paulo - SP/Brazil