> I updated the RFC a few hours ago based on a lengthy discussion in> > php-standards.
Point of order. Discussions on RFCs are supposed to happen on the internals list. That's the point of an open RFC process, so that the discussion and justification can be made public for all to see. The RFCs under discussion should not be changed during this time with the exception of changes requested in the formal discussion. If the RFC was changing during the discussion phase due to closed-door discussions, then I think that it voids the discussion phase entirely. Why am I so adamant against this RFC? Simple: the implementation won't do what people have been promised. There are dozens of *different* PSR-0 implementations out there (Heck, Symfony has **5** of them). Why are we trying to lock the core down to the most limiting version? And at that point, why isn't the http://pecl.php.net/package/automap Automap extension being considered for inclusion instead/in addition? Rather than trying to find the *right* solution for the core, the focus has been on *a* solution. That's the wrong approach in my opinion and I fear that projects and users will suffer in the long run. And that doesn't even hint at the deficiencies that others and myself have pointed out with PSR-0 itself. I don't want to beat a dead horse here, but I still think that it's important to solidify the RFC prior to the voting phase can legitimately happen. Otherwise people are voting on a moving target (which isn't reasonable IMHO). I won't bring it up again, but I feel it's important to assert this officially... Anthony On Mon, Nov 7, 2011 at 12:41 PM, guilhermebla...@gmail.com <guilhermebla...@gmail.com> wrote: > Hi Ivan, > > I updated the RFC a few hours ago based on a lengthy discussion in > php-standards. > It seems after these 2 years of PSR-0, all the rules are kept, but > some changes were made to the original code (the one in RFC) to > enhance the support. They are: > > - Multiple paths per namespace > - Silent mode > > The first one seems very useful in a component based library, while > the second is intended to not explode the class required if you have > multiple instances of ClassLoader. > I added quickly the methods ->registerNamespace() and > ->registerPrefix() to RFC, but I still require to update the > SplClassLoader PHP based version. > > By now, you can either look at Symfony 2, Doctrine 2 or Zend Framework > 2 to see the implementation details. > > Cheers, > > On Mon, Nov 7, 2011 at 3:36 PM, Ivan Enderlin @ Hoa > <ivan.ender...@hoa-project.net> wrote: >> On 07/11/11 14:41, David Coallier wrote: >>> >>> Hey everyone, >> >> Hi David, >> >>> After lengthy discussions and various opinion, we believe this issue >>> has been discussed at length and the PSR-0 has had this standard >>> effective for the past 1.5 year. >>> >>> The SplClassLoader RFC has moved to "voting" stage. Please cast your >>> votes at https://wiki.php.net/rfc/splclassloader/vote >>> >>> Thank you very much for all the interest showed so far, >> >> I'm very interesting by SplClassLoader but the RFC is not consistent. You >> give an example that actually does not follow the proposed implementation >> (e.g. the registerNamespace() and registerPrefix() methods are not present >> in the proposed implementation). >> >> I have a solution in Hoa (a set of libraries, please, see my signature) for >> supporting multiple paths per namespace. How can I contribute knowing that >> Hoa's implement follows the RFC (since it's beginning). >> >> Best regards. >> >> -- >> Ivan Enderlin >> Developer of Hoa >> http://hoa.42/ or http://hoa-project.net/ >> >> PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis) >> http://lifc.univ-fcomte.fr/ and http://www.inria.fr/ >> >> Member of HTML and WebApps Working Group of W3C >> http://w3.org/ >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > 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
