Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56192 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16359 invoked from network); 9 Nov 2011 14:45:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Nov 2011 14:45:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=petercowburn@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=petercowburn@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender) X-PHP-List-Original-Sender: petercowburn@gmail.com X-Host-Fingerprint: 209.85.216.177 mail-qy0-f177.google.com Received: from [209.85.216.177] ([209.85.216.177:38158] helo=mail-qy0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2C/40-13830-7F19ABE4 for ; Wed, 09 Nov 2011 09:45:12 -0500 Received: by qyk10 with SMTP id 10so1733323qyk.8 for ; Wed, 09 Nov 2011 06:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=QxlWk+U6kvvZZP1htW7PK+J3qzrxShoDOeJJszA3Ryc=; b=Qs6YXDQ+dC10ADwd7Kac6Re5PFWJE6viQBoazsbM2ePuKLc+VG1mxotyc9WPUbFdci 5KD8suAcoMkYuQfudk8Z40RlDq90iHwrZtDaNrVLtapmZ/ZchMEMjYfGjQKn3kBhMNJ2 jFhza1iggGvPdzvIyG5pMvbTLyg7BuEBI4jA4= Received: by 10.68.0.68 with SMTP id 4mr5782811pbc.51.1320849908757; Wed, 09 Nov 2011 06:45:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.63.169 with HTTP; Wed, 9 Nov 2011 06:44:27 -0800 (PST) In-Reply-To: References: <4EB81703.7030605@hoa-project.net> <4EB81C84.8010609@hoa-project.net> <4EB820BB.2030009@lsces.co.uk> <4EB822D4.4060306@hoa-project.net> <4EB89C36.5000503@garfieldtech.com> <4EB8A22B.8000607@lerdorf.com> Date: Wed, 9 Nov 2011 14:44:27 +0000 Message-ID: To: Christian Kaps Cc: internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] SplClassLoader RFC Voting phase From: petercowburn@gmail.com (Peter Cowburn) 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. =A0If 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 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 SplClassLoad= er > interface and defines the methods register and unregister. > > interface SplClassAutoloader extends SplClassLoader { > > =A0 =A0public function register($prepend =3D false); > > =A0 =A0public function unregister(); > } > > As a side note, the two interfaces doesn't violate the Single responsibil= ity > 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 =3D new MyCustomClassLoader(); > spl_autoload_register(array($classLoader, 'load')); > > But the following syntax seems more consistent to me: > > $classLoader =3D new MyCustomClassLoader(); > spl_autoload_register($classLoader); > > Christian > > Am 09.11.2011 02:23, schrieb guilhermeblanco@gmail.com: >> >> For all those interested, I implemented what I referred as item 2: >> >> >> 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. >> >> >> 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, guilhermeblanco@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/Cl= assLoader/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 >>> wrote: >>>> >>>> On Tue, Nov 8, 2011 at 6:28 PM, 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 >>>> >>> >>> >>> >>> -- >>> Guilherme Blanco >>> Mobile: +55 (11) 8118-4422 >>> MSN: guilhermeblanco@hotmail.com >>> S=E3o Paulo - SP/Brazil >>> >> >> >> >> -- >> Guilherme Blanco >> Mobile: +55 (11) 8118-4422 >> MSN: guilhermeblanco@hotmail.com >> S=E3o Paulo - SP/Brazil > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >