Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements

Anthony Ferrara wrote: Since you asked me for feedback on how I would suggest improving the RFC, so here it goes... Silly question time ... If I am reading all this correctly we are talking about how something is found if I have not directly identified that I want to use it? So if my base fr

Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements

David Sorry, I just RE read your reply. that's basically what you said, so in essence I agree... Anthony On Nov 10, 2011 6:29 PM, "Anthony Ferrara" wrote: > Well, the problem with adding methods later is that it will fatal any > class that implements the old one. A big no no. > > You could g

Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements

Well, the problem with adding methods later is that it will fatal any class that implements the old one. A big no no. You could get around that by doing something like traversable. Provide an empty and non usable core SplAutoloader interface which is typehintable. Then add a child SplClassAutolo

Re: [PHP-DEV] SPLClassLoader RFC Thoughts And Improvements

Surprised to say that I agree on just about everything you mentioned. I would however love to see a useful autoloader included in core. I have only one comment below. > 4. The RFC should avoid implementing any pattern or style that may > make future feature addition difficult or pose risks towards

Re: [PHP-DEV] SplClassLoader RFC Voting phase

2011/11/10 Pierre Joye : > On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT >> Some are blocking because they kinda feel forced if this is introduced. >> Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons >> about 15 years ago. >> >> I guess that some voted "No" because of lack

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 11/10/11 8:19 AM, Pierre Joye wrote: What amazes me is this exact argument. We never had, in the whole PHP history, so many leading projects agreeing on something, together and propose it to the core. I, for one, have been waiting for that to happen for years (PEAR, etc.), and now that it is

Re: [PHP-DEV] SplClassLoader RFC Voting phase

> 2) This isn't a "bunch" of developers, this is a bunch of the largest> used > PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal), Ok, I have to say it... You're a group of people who have done great things. Good for you. Get over it. Stop trying to use that as a justification or

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Comments are inline. On Thu, Nov 10, 2011 at 2:19 PM, Pierre Joye wrote: > On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT > wrote: > >> You're mixing stuff here. >> "RFC on PSR-0 support into PHP status" != "PSR-0 status" > > I do not. But we are confusing our old vision and what users are lo

[PHP-DEV] SPLClassLoader RFC Thoughts And Improvements

Guilherme et al, Since you asked me for feedback on how I would suggest improving the RFC, so here it goes... I think I need to make one thing clear first. I don't think that I can vote yes for this RFC in principle (I just don't agree this belongs in core). However, with that said if the RFC w

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT wrote: > You're mixing stuff here. > "RFC on PSR-0 support into PHP status" != "PSR-0 status" I do not. But we are confusing our old vision and what users are looking for. > However, *how* PSR-0 might be introduced into PHP, for those who uses >

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Thu, Nov 10, 2011 at 11:00 AM, Stas Malyshev wrote: > Nobody's blocking anything. See the votes, that's pretty much us vs the rest. And it is not the 1st time (happened already in the past before we had the RFC process, so it will become more and more visible. >> And as far as I can see, the

Re: [PHP-DEV] SplClassLoader RFC Voting phase

2011/11/10 Pierre Joye : > hi Stas, > > On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev wrote: >> Hi! >> >>> This attitude only makes me lose a lot of time answering questions >>> instead of focusing on actual RFC stability. I want to propose >>> something stable, I do not want to be pressured abou

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi! But blocking the only thing so many PHP projects have ever agreed on is a major mistake. And it is a political and religious choice (religious as in "php does not enforce standard"). Even for something that does not enforce anything if not used. Nobody's blocking anything. I don't understa

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Thu, Nov 10, 2011 at 10:36 AM, Pierre Joye wrote: > hi Stas, > > On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev > wrote: > > Hi! > > > >> This attitude only makes me lose a lot of time answering questions > >> instead of focusing on actual RFC stability. I want to propose > >> something stabl

Re: [PHP-DEV] SplClassLoader RFC Voting phase

hi Stas, On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev wrote: > Hi! > >> This attitude only makes me lose a lot of time answering questions >> instead of focusing on actual RFC stability. I want to propose >> something stable, I do not want to be pressured about should the RFC >> exist or not. I

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi! This attitude only makes me lose a lot of time answering questions instead of focusing on actual RFC stability. I want to propose something stable, I do not want to be pressured about should the RFC exist or not. It only delays the real voting results. What I can do to address this? I woul

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi, @RDohms What you said is pretty valid. If you're not going to use it, you vote against it? You may not use it, but many others can. It's a true state. @Anthony I already heard your points many times. I know you're against it. I also know the voting should be reset, but before the reset, I w

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Wed, Nov 9, 2011 at 8:49 PM, Anthony Ferrara wrote: > On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms > wrote: >> On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote: > > I am not PSR compliant in either autoloader implementation or class > implementation.  The reason is that over time I have

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms wrote: > On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote: > > You sort of prove my point here, as you actually have your own > autoloader, which in case you are PSR compliant, you would not need, > you can still use your bootstrap but no longer

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote: > Rafael > >> This makes life as a PHP developer much easier and having the standard> >> "valued" by PHP by having a SplClassLoader that allows any library to> not >> need to implement a autolaoder if no framework is present allows> for much

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6: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 ->

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi! - I think it's too late in PHP 5.4's release cycle to be proposing anything for 5.4. Not talking about the merits of the loader, if it comes into 5.4, that won't be 5.4.0. Unless we discover some very bad problem, 5.4 is going into RC tomorrow, which means I will be extremely reluctant t

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 9 November 2011 22:44, Peter Cowburn wrote: > I am removing my vote due to a particularly annoying aspect of this > whole RFC/voting structure: the RFC is still in flux! This is one of the reasons why I've voted -1: there's no way an RFC should be changing this much (or at all, really) while v

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Rafael > This makes life as a PHP developer much easier and having the standard> > "valued" by PHP by having a SplClassLoader that allows any library to> not > need to implement a autolaoder if no framework is present allows> for much > nicer "plug and play" interaction of libraries, less work

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Wed, Nov 9, 2011 at 12:04 AM, Will Fitch wrote: > ... > I have to say, I've never heard the argument, "man, if there's one > thing I'd like to standardize in PHP, it'd definitely be autoloading > classes."  No, indeed I believe this is a group of frameworks trying > to implement a standard into

Re: [PHP-DEV] SplClassLoader RFC Voting phase

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 dis

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 09/11/11 11:24, Christian Kaps wrote: Hi, Hi Christian :-), 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 de

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 08/11/11 18:39, Nikita Popov wrote: On Tue, Nov 8, 2011 at 6:28 PM, 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 A

Re: [PHP-DEV] SplClassLoader RFC Voting phase

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

Re: [PHP-DEV] SplClassLoader RFC Voting phase

2011/11/8 guilhermebla...@gmail.com : > Ok... I promised to complete the RFC and here I am. > > I wrapped the entire idea, PHP implementation of what I'm proposing all in > RFC. > If you're interested, feel free to review the document, highlight if I > missed something and update/add your votes. >

Re: [PHP-DEV] SplClassLoader RFC Voting phase

I don't argue with your logic and want for standards. I do question this implementation. This is will not enforce any standards whatsoever and I feel it serves the need for existing frameworks and standardizing them. I have to say, I've never heard the argument, "man, if there's one thing I'd like

Re: [PHP-DEV] SplClassLoader RFC Voting phase

PS: I'd love to point you all this article... this is something that motivates me to push this RFC forward. =) http://phpmaster.com/the-importance-of-standards/ Cheers, On Tue, Nov 8, 2011 at 11:23 PM, guilhermebla...@gmail.com wrote: > For all those interested, I implemented what I referred as

Re: [PHP-DEV] SplClassLoader RFC Voting phase

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 Cac

Re: [PHP-DEV] SplClassLoader RFC Voting phase

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 s

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6:28 PM, 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 R

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi Nikita, 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. Cheers, On Tue, Nov 8, 2011 at 3:25 PM, Nikita Popov wrote: > On Tue, Nov 8, 2011 a

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6:17 PM, guilhermebla...@gmail.com wrote: > Remove is useless. conditionally add loaders and you're done. > AddAll is ok for user land, but we focus on basic stuff, not fluffy > implementations. It can be easily done in userland. ... Just like the whole rest of the class: al

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Ok... I promised to complete the RFC and here I am. I wrapped the entire idea, PHP implementation of what I'm proposing all in RFC. If you're interested, feel free to review the document, highlight if I missed something and update/add your votes. http://wiki.php.net/rfc/splclassloader Answering

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 11/07/2011 07:04 PM, Larry Garfield wrote: > If anything, the low degree of communication between "people who write > PHP" and "people who write in PHP" is, and has long been, one of PHP's > great weaknesses. I think this entire thread has shown that very well. > That is something that needs

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 11/07/2011 01:42 PM, Ferenc Kovacs wrote: On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa< ivan.ender...@hoa-project.net> wrote: On 07/11/11 19:17, Lester Caine wrote: guilhermebla...@gmail.com wrote: To participate of php-standards group, feel free to join here: http://groups.goo

Re: [PHP-DEV] SplClassLoader RFC Voting phase

> 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

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Mon, Nov 7, 2011 at 7:26 PM, Ivan Enderlin @ Hoa < ivan.ender...@hoa-project.net> wrote: > > > On 07/11/11 19:17, Lester Caine wrote: > >> guilhermebla...@gmail.com wrote: >> >>> To participate of php-standards group, feel free to join here: >>> http://groups.google.com/**group/php-standards

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 07/11/11 19:17, Lester Caine wrote: guilhermebla...@gmail.com wrote: To participate of php-standards group, feel free to join here: http://groups.google.com/group/php-standards Not while it's not a php list ... +1. It would be great if PHP could host this mailing-list. It would be an ac

Re: [PHP-DEV] SplClassLoader RFC Voting phase

guilhermebla...@gmail.com wrote: To participate of php-standards group, feel free to join here: http://groups.google.com/group/php-standards Not while it's not a php list ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electro

Re: [PHP-DEV] SplClassLoader RFC Voting phase

guilhermebla...@gmail.com wrote: Hi Anthony, On Mon, Nov 7, 2011 at 3:43 PM, Anthony Ferrara wrote: Actually, I just re-read the RFC again and I noticed something that's really irksome to me: Implementation extension According to new threads in php-standards list, it seems all derived im

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 07/11/11 19:05, guilhermebla...@gmail.com wrote: Hi Ivan, Hi :-), The PSR-0 went to Final Release 2 years ago. It's not possible to change it anymore. If you find relevant items, you can open another PSR for discussion. But be aware that autoloading ones would be likely rejected since we al

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Am 07.11.2011 18:36, schrieb guilhermebla...@gmail.com: > Point #4 would probably turn ClassLoader useless ... which it is in my opinion hence my request to include that option in the voting process. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi Ivan, On Mon, Nov 7, 2011 at 3:59 PM, Ivan Enderlin @ Hoa wrote: > > > On 07/11/11 18:41, guilhermebla...@gmail.com wrote: >> >> Hi Ivan, > > Hi, > >> >> 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

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi Anthony, On Mon, Nov 7, 2011 at 3:43 PM, Anthony Ferrara wrote: > Actually, I just re-read the RFC again and I noticed something that's > really irksome to me: > >> Implementation extension > >> According to new threads in php-standards list, it seems all derived >> implementations have inclu

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 07/11/11 18:41, guilhermebla...@gmail.com wrote: Hi Ivan, Hi, 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 s

Re: [PHP-DEV] SplClassLoader RFC Voting phase

I don't disagree with your assessment. I would like to add that the framework standards group, in this case, should consider standardizing the frameworks rather than PHP based on their needs. There's no reason the members of your group can't reach a consensus to develop a loader that is distribute

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Actually, I just re-read the RFC again and I noticed something that's really irksome to me: > Implementation extension > According to new threads in php-standards list, it seems all derived > implementations have included these extensions to original support: > Multiple paths per namespace > Si

Re: [PHP-DEV] SplClassLoader RFC Voting phase

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

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi, It seems we would never reach some consensus, so I prefer to stick to the voting process. Looks like it's another battle between core developers and framework core developers, where the first ones don't see a benefit at all and have to opt for a side while the other side is eagerly requesting

Re: [PHP-DEV] SplClassLoader RFC Voting phase

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 ca

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Well, with respect to that, are there any examples of where PHP currently "reserves the namespace"? I can declare functions/classes for every single disablable/PECL extension right now. So is there even a method to "reserve a namespace", yet alone enforce that in core? And with respect to the re

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Anthony Ferrara wrote: Lester, I think he was referring to something like the MySQL/bcmath/etc extension where it ships in core, but is disabled by default (requires a compile-time option). I think what you interpreted it as is basically just what PECL is for and how it works? Considering that

Re: [PHP-DEV] SplClassLoader RFC Voting phase

I know this topic has been discussed enough, but I think one argument was not brought up yet. The proposed solution has a bad OO design because it violates against the "Single responsibility principle". Another issue is that the proposed class is only one possible solution to load PSR-0 conform

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Lester, I think he was referring to something like the MySQL/bcmath/etc extension where it ships in core, but is disabled by default (requires a compile-time option). I think what you interpreted it as is basically just what PECL is for and how it works? Considering that it would basically be ju

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Sebastian Bergmann wrote: 1- The same as you wrote. Having it in SPL and in PHP 5.4 > 2- Have it in PHP 5.4 as an external extension (FIG, PSR or PSG), > enabled by default. > 3- As an external extension, disabled by default. This would require > PHP core to reserve the namespace for us. Y

Re: [PHP-DEV] SplClassLoader RFC Voting phase

That would be even better On Nov 7, 2011, at 10:59 AM, Sebastian Bergmann wrote: > Am 07.11.2011 15:29, schrieb guilhermebla...@gmail.com: >> 1- The same as you wrote. Having it in SPL and in PHP 5.4 >> 2- Have it in PHP 5.4 as an external extension (FIG, PSR or PSG), >> enabled by default. >

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Am 07.11.2011 15:29, schrieb guilhermebla...@gmail.com: > 1- The same as you wrote. Having it in SPL and in PHP 5.4 > 2- Have it in PHP 5.4 as an external extension (FIG, PSR or PSG), > enabled by default. > 3- As an external extension, disabled by default. This would require > PHP core to reserve

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Nov 7, 2011, at 10:50 AM, Anthony Ferrara wrote: > Well, my only concern with splitting it into the three questions is > that the RFC specifically mentioned putting it in SPL. > > So there wasn't really any discussion or RFC of either of the other > two points. While it's not really a big de

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Well, my only concern with splitting it into the three questions is that the RFC specifically mentioned putting it in SPL. So there wasn't really any discussion or RFC of either of the other two points. While it's not really a big deal, I think that #3 at least requires some more discussion as it

Re: [PHP-DEV] SplClassLoader RFC Voting phase

I agree with Guilherme on this one. The voting objective seems very vague currently. On Mon, Nov 7, 2011 at 12:29 PM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > I'd rather suggest to split this poll into 3 questions: > > 1- The same as you wrote. Having it in SPL and in PHP 5

Re: [PHP-DEV] SplClassLoader RFC Voting phase

I'd rather suggest to split this poll into 3 questions: 1- The same as you wrote. Having it in SPL and in PHP 5.4 2- Have it in PHP 5.4 as an external extension (FIG, PSR or PSG), enabled by default. 3- As an external extension, disabled by default. This would require PHP core to reserve the names

[PHP-DEV] SplClassLoader RFC Voting phase

Hey everyone, 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/splclassloade

Re: [PHP-DEV] SplClassLoader

my comments are also inline > > did you read the blogpost? most of your replies were cowered there. > > > > Yes. you mean you or André? > > "If you use lowerCamelCase on the class names or your namespace, it will > > (/should) be exactly like on disk as well." > > > > So as previously said,

Re: [PHP-DEV] SplClassLoader

Guilherme, > The language is problematic, FIG/PSG are just trying to have zillions > different implementations. Everyone would expect that language to set > the standards, avoiding millions of weird pieces of code out there. Actually, I'd argue that what you're saying here is the exact opposite o

Re: [PHP-DEV] SplClassLoader

Guilherme, What's the status regarding the finalised PSR-0 implementation so we can hand it over to DavidC to finish the C implementation and apply this to 5.4 branch. Cheers, - Paul On Fri, Nov 4, 2011 at 5:27 PM, guilhermebla...@gmail.com wrote: > Hi Tyra3l, > > Comments are inline. > > On Fr

Re: [PHP-DEV] SplClassLoader

Hi Tyra3l, Comments are inline. On Fri, Nov 4, 2011 at 8:35 AM, Ferenc Kovacs wrote: > On Fri, Nov 4, 2011 at 10:33 AM, André Rømcke wrote: > >> On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara >> wrote: >> >> > Paul, >> > >> > I wasn't saying whether it should be included or not.  I was saying

Re: [PHP-DEV] SplClassLoader

On Nov 4, 2011, at 7:19 AM, Anthony Ferrara wrote: > Jonathan, > >> The problem with spl_autoload_register() is it isn't clear what the >> autoloading function is supposed to do if the class if not found. > > Then that's a documentation problem. If you throw an exception in > yours, sure that's

Re: [PHP-DEV] SplClassLoader

Jonathan, > The problem with spl_autoload_register() is it isn't clear what the > autoloading function is supposed to do if the class if not found. Then that's a documentation problem. If you throw an exception in yours, sure that's going to cause problems for anyone else. It's 100% possible (a

RE: [PHP-DEV] SplClassLoader

On Thu Nov 3 03:06 PM, Will Fitch wrote: > Wouldn't you consider spl_autoload_register an interoperability > solution? Only your defined autoloading function would then need to > know how your file system is structured, there'd be no need for > include_path declarations and you wouldn't have to

Re: [PHP-DEV] SplClassLoader

On Fri, Nov 4, 2011 at 10:33 AM, André Rømcke wrote: > On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara > wrote: > > > Paul, > > > > I wasn't saying whether it should be included or not. I was saying > > that performance should not be a justification for it being included. > > It may be a benefi

Re: [PHP-DEV] SplClassLoader

On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara wrote: > Paul, > > I wasn't saying whether it should be included or not. I was saying > that performance should not be a justification for it being included. > It may be a benefit, but it's a very small side benefit as opposed to > a primary one. >

Re: [PHP-DEV] SplClassLoader

2011/6/27 guilhermebla...@gmail.com : > Hannes, > > There's a RFC covering this. There's a patch also. > > https://wiki.php.net/rfc/splclassloader I do have a few remarks: 1. That is not a *class* loader, that is a loader (also for interfaces), hence my suggestion s/SplClassLoader/SplLoader/ 2. PS

Re: [PHP-DEV] SplClassLoader

Wouldn't you consider spl_autoload_register an interoperability solution? Only your defined autoloading function would then need to know how your file system is structured, there'd be no need for include_path declarations and you wouldn't have to explicitly declare paths for each class. On Nov

RE: [PHP-DEV] SplClassLoader

On Thu Nov 3 11:19 AM, Anthony Ferrara wrote: > > But that's besides the point. I just want to emphasize the point that > performance should not be a criteria for justifying it going into the > core... > There also seems to be the perception among some php devs that autoloading is now the pre

Re: [PHP-DEV] SplClassLoader

Paul, I wasn't saying whether it should be included or not. I was saying that performance should not be a justification for it being included. It may be a benefit, but it's a very small side benefit as opposed to a primary one. Additionally, I wholeheartedly disagree with one of your points ther

Re: [PHP-DEV] SplClassLoader

On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara wrote: > Can I make a point here. > > Why the heck are we caring about the performance of the autoloader at > all here?  The filesystem operations necessary (at least the stat() > call) will greatly dominate any string function.  And considering that

Re: [PHP-DEV] SplClassLoader

On Thu, Nov 3, 2011 at 4:19 PM, Anthony Ferrara wrote: > Can I make a point here. > > Why the heck are we caring about the performance of the autoloader at > all here? The filesystem operations necessary (at least the stat() > call) will greatly dominate any string function. And considering tha

Re: [PHP-DEV] SplClassLoader

I couldn't agree more with Anthony. In conjunction with that, I would continue to question the full benefit to the community. How many existing code bases/frameworks out there would implement this in favor of their existing solution? Will On Nov 3, 2011, at 11:19 AM, Anthony Ferrara wrote:

Re: [PHP-DEV] SplClassLoader

Can I make a point here. Why the heck are we caring about the performance of the autoloader at all here? The filesystem operations necessary (at least the stat() call) will greatly dominate any string function. And considering that even the biggest framework only has perhaps a few hundred classe

Re: [PHP-DEV] SplClassLoader

On Thu, Oct 27, 2011 at 4:30 AM, Laruence wrote: > 2011/10/26 André Rømcke : > > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < > > guilhermebla...@gmail.com> wrote: > > > >> Hi internals, > >> > >> For all those interested, I have updated the RFC with better > >> explanation, inclu

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

On 2011-10-28, Nicolas Grekas wrote: > About PSR-0 and applying the same reasoning, I don't understand why > the underscore in the namespace part is not replaced by a directory > separator: because of it's class to path transformation, PSR-0 forbids > having two different classes named A\B_C and

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

To me, the interface found at https://wiki.php.net/rfc/splclassloader is strange : first, to be consistent with PSR-0, why allow changing the extension where PSR-0 states that the only valid one is ".php"? Why also have an interface to change the namespace separator? Concerning userland specializ

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

Hello, > Already answered before. Performance is important. A native C > > implementation is much faster than a PHP code implementation. > > Well, that's always a safe assumption. But a shiny benchmark would be > useful in this review. > Interesting hard fact would to be know if -for the overall f

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

Hello Guilherme, 2011/10/27 guilhermebla...@gmail.com : > > PHP-Standard list is also opened. ... since a few days. But I'll happily take the discussion there. As I feel it doesn't belong here. Discussing PSR-0 or how it came to be is entirely off-topic (and would be rude). We are just discussin

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

On 2011-10-26, Pierre Joye wrote: > On Thu, Oct 27, 2011 at 1:07 AM, wrote: > > 2011/10/26 Matthew Weier O'Phinney : > > > My main point, however, is that the standard was ratified quite some > > > time ago already -- we just now have parties interested in creating a > > > C-level implementation

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

Hi Mario, On Wed, Oct 26, 2011 at 9:07 PM, wrote: > 2011/10/26 Matthew Weier O'Phinney : >> >> My main point, however, is that the standard was ratified quite some >> time ago already -- we just now have parties interested in creating a >> C-level implementation compatible with the standard to (

Re: [PHP-DEV] SplClassLoader

2011/10/26 André Rømcke : > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> Hi internals, >> >> For all those interested, I have updated the RFC with better >> explanation, included example implementation and also example usage. >> If you have a

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

On Thu, Oct 27, 2011 at 1:07 AM, wrote: > 2011/10/26 Matthew Weier O'Phinney : >> >> My main point, however, is that the standard was ratified quite some >> time ago already -- we just now have parties interested in creating a >> C-level implementation compatible with the standard to (a) make usa

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

2011/10/26 Matthew Weier O'Phinney : > > My main point, however, is that the standard was ratified quite some > time ago already -- we just now have parties interested in creating a > C-level implementation compatible with the standard to (a) make usage > simpler, and (b) better optimize performanc

Re: [PHP-DEV] SplClassLoader

On 2011-10-26, André Rømcke wrote: > --bcaec5216025460b0e04b031fc2a > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > For all those interested, I have up

Re: [PHP-DEV] SplClassLoader

On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei wrote: > I think the following two requirements should be covered by configuration > aswell: > > 1. Have the autoloader be silent, i.e. doing a file_exists() check. API > idea > $loader = new SplClassLoader(..., SplClassLoader::SILENT); > 2. Have

Re: [PHP-DEV] SplClassLoader

On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Hi internals, > > For all those interested, I have updated the RFC with better > explanation, included example implementation and also example usage. > If you have any other wishes, doubts, etc, feel f

Re: [PHP-DEV] SplClassLoader

I think the following two requirements should be covered by configuration aswell: 1. Have the autoloader be silent, i.e. doing a file_exists() check. API idea $loader = new SplClassLoader(..., SplClassLoader::SILENT); 2. Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an "if(!class_exists(

Re: [PHP-DEV] SplClassLoader

Hi internals, For all those interested, I have updated the RFC with better explanation, included example implementation and also example usage. If you have any other wishes, doubts, etc, feel free to ask on this thread and I'll quickly answer here and also update the RFC accordingly. The url for

Re: [PHP-DEV] SplClassLoader

> > Could you open a FR at bugs.php.net and attach the patch to it please? > Could be easier to track  (and the # to the RFC too :) > Yeah I'll do that once I have the tests adjusted and once I know the patch actually works as expected. -- David Coallier -- PHP Internals - PHP Runtime Developme

  1   2   >